Ética jurídica en EE. UU. e IA generativa — ABA Formal Opinion 512 (29 de julio de 2024) y las Model Rules que aplica
Esta página se genera a partir de la tabla de requisitos que el motor de AiSSAY incluye para este marco. Cuando el motor produce un paquete de evidencias, cada fila de abajo recibe un estado calculado a partir de los propios registros del operador en ese momento. Esta página muestra la tabla, no los resultados de nadie.
Correspondencia informativa preparada con las propias herramientas del operador. No es un dictamen jurídico, ni una certificación, ni sustituye el asesoramiento de un abogado. Organiza los registros del operador en relación con los requisitos citados; determinar si esos registros cumplen los requisitos corresponde al operador, a su asesor jurídico y al examinador.
Las opiniones de la ABA son orientativas. Solo vinculan a un abogado en la medida en que su propio estado adopte la norma o la postura. Los plazos de conservación del expediente del cliente se fijan estado por estado; la Model Rule 1.15 propone entre corchetes cinco años para los registros fiduciarios como valor provisional. Hasta septiembre de 2026 no se había emitido ninguna opinión formal posterior de la ABA sobre IA.
La tabla de requisitos
10 filas: 5 de mecanismo, 4 organizativas, 1 carencia señalada
| Requisito | Mecanismo, obligación o carencia | Tipo |
|---|---|---|
| Model Rule 1.1 — competencia: entender lo que la herramienta de IA puede y no puede hacer, y mantener ese conocimiento actualizado | organizativo: el conocimiento corresponde al abogado. Las indicaciones del registro sobre lo que el agente no pudo verificar, y nuestra medición de dónde los modelos pasan por alto sus propios errores, son elementos que alimentan ese conocimiento, no un sustituto. | organizativo |
| Model Rule 1.6 — proteger la información del cliente que se usa con herramientas de IA | registros sellados en los propios equipos de la firma bajo su clave, sin copia del lado del proveedor; cada lectura, exportación y eliminación queda registrada; borrado criptográfico con una marca de borrado que demuestra que el registro existió | mecanismo |
| Model Rule 1.6 — consentimiento informado del cliente antes de que la información confidencial entre en una herramienta con autoaprendizaje | organizativo: obtener el consentimiento corresponde al abogado, y la Opinion 512 dice que una cláusula estándar en la carta de encargo no basta | organizativo |
| Model Rules 3.1, 3.3 y 8.4(c) — los resultados de la IA se verifican antes de llegar a un tribunal | las cifras y las citas de cada ejecución se cotejan con las fuentes que invocan; se plantean hallazgos y se marcan ejecuciones para revisión; el refrendo de un revisor designado se sella junto a la ejecución. La verificación en sí corresponde al abogado. | mecanismo |
| Model Rules 5.1 y 5.3 — supervisión de abogados, personal y proveedores que usan IA | quién revisó cada ejecución, y cuándo, consta en la cadena junto a la ejecución; las retenciones de acciones irreversibles muestran qué se detuvo a la espera de una decisión. Las políticas de supervisión corresponden a la firma. | mecanismo |
| Model Rules 1.4 y 1.5 — informar a los clientes sobre el uso de IA, y honorarios razonables por trabajo asistido por IA | organizativo: la información al cliente y el criterio de facturación corresponden al abogado. Las marcas de tiempo del registro sellado pueden respaldar una pregunta sobre facturación; no la responden. | organizativo |
| Model Rule 1.16(d) — entregar los documentos y bienes a los que el cliente tiene derecho cuando termina la representación | exportación completa de todos los registros en cualquier momento, con la cadena para demostrar que la exportación está completa para su periodo | mecanismo |
| Formal Opinion 520 (enero de 2026) — responder a las solicitudes de información de un antiguo cliente o del abogado que lo sucede, que pueden incluir información que nunca se puso por escrito | organizativo: decidir qué necesita un antiguo cliente o el abogado que lo sucede, y transmitir lo que nunca se registró, corresponde al abogado. Los registros sellados solo pueden aportar lo que se capturó. | organizativo |
| Conservación del expediente del cliente y de los registros fiduciarios (normas estatales) | fechas de conservación por registro, fijadas cuando se sella un registro (siete años por defecto); la eliminación antes de esa fecha se rechaza salvo que conste una autorización excepcional registrada; la retención legal bloquea la eliminación por completo | mecanismo |
| Uso de los registros de esta herramienta como evidencia — evaluación independiente de sus controles | NO IMPLEMENTADO. Todavía no existe ninguna prueba de penetración, ninguna revisión de la criptografía por terceros ni ningún informe independiente sobre los controles de este software. Quien utilice estos registros como evidencia debe evaluar la herramienta por sí mismo, y esta fila lo dice en primer lugar. | carencia señalada |
Cómo se obtiene un estado
- Acreditado
- se ejecutó una comprobación determinista sobre sus registros y los recuentos respaldan la fila. Un almacén que no contiene registros pertinentes figura como no acreditado: una afirmación verdadera, no un aprobado. Vacío nunca cuenta como limpio.
- Delegado
- el mecanismo lo hace cumplir un sistema en el que usted ya confía: un almacén sellado por su propio gestor de claves le delega a este el control de acceso, y el paquete indica que el registro que lo hace cumplir es el de su gestor de claves, no el nuestro. El paquete nombra el endpoint en el que se contactó con el gestor de claves. Un endpoint de AWS distinto del predeterminado de AWS para la región figura como delegado a ese endpoint, con una solicitud para que usted confirme que es su servicio de gestión de claves. Un backend —AWS KMS— se ha ejecutado contra el servicio real de AWS KMS; ningún otro backend lo ha hecho.
- Punto de integración de prueba
- sellado por un backend de prueba dentro del proceso —un stub, o un sustituto del cliente de AWS— y el estado indica cuál. Ningún gestor de claves controla el acceso. El punto de integración está construido y probado, y el paquete se niega a llamar a eso delegación.
- Parcialmente acreditado
- el mecanismo está construido y algunas de sus ejecuciones llevan su evidencia, pero no todas, normalmente porque se sellaron antes de que existiera el mecanismo. El paquete indica cuántas ejecuciones hay en cada grupo y nunca cuenta como aprobadas las que faltan.
- Organizativo
- el requisito es un procedimiento que solo pueden llevar a cabo personas. El paquete lo señala como responsabilidad suya en lugar de disfrazar una política de mecanismo.
- Carencia señalada
- el paquete no puede acreditarlo —o bien el mecanismo no está construido, o bien ningún software puede aportarlo— y dice cuál de los dos casos es. La carencia se imprime, porque un revisor debería leerla aquí y no descubrirla después.
Ningún estado se introduce a mano: cada estado se recalcula a partir del almacén cada vez que se produce un paquete, el texto de los requisitos y de los mecanismos se redacta y revisa como parte del motor, y la evidencia sobre dependencias procede de nuestro análisis de cada versión. Un mecanismo que falla nunca puede interpretarse como evidencia de que el control funciona.