Análisis del Proyecto de Reglamento para el desarrollo y uso responsable de la Inteligencia Artificial (Resolución RSC-1719-2026). Consulta pública abierta hasta el 7 de agosto de 2026.

I. EL PUNTO DE PARTIDA: UN MARCO QUE LLEGA TARDE PERO MEJOR QUE TARDE

Hay abogados bonaerenses que ya usan ChatGPT para redactar escritos. Hay peritos que generan con IA el grueso de sus dictámenes y los suscriben. Hay secretarios que verifican jurisprudencia con LLMs y magistrados que usan herramientas de generación de texto para proyectar sentencias. Ninguno de ellos operó hasta ahora bajo un marco regulatorio claro. Ninguno sabía con precisión qué estaba haciendo bien y qué los exponía.

Eso cambió el 19 de junio de 2026.

La Suprema Corte de Justicia de la Provincia de Buenos Aires registró ese día la Resolución RSC-1719-2026, suscripta por los jueces Sergio Torres, Hilda Kogan y Daniel Soria, y aprobó como Anexo I el Proyecto de Reglamento para el desarrollo y uso responsable de la Inteligencia Artificial. La Resolución RP 747/26, posterior, amplió el período de consulta pública hasta el 7 de agosto de 2026. Hasta tanto se apruebe su versión definitiva, el Proyecto tiene carácter orientador y no vinculante (art. 5 de la Resolución). La versión definitiva será vinculante.

Este artículo no resume el Proyecto. Lo analiza desde tres ángulos que coexisten en cualquier expediente bonaerense: el abogado litigante, el perito y el magistrado o funcionario que usa IA en sus despachos. El foco no está en los aciertos del Proyecto, que los tiene, sino en las consecuencias prácticas de sus omisiones y en los argumentos que esas omisiones habilitan en el proceso.

II. LA ARQUITECTURA DEL PROYECTO: LO QUE ESTÁ BIEN Y POR QUÉ IMPORTA ENTENDERLO

Antes de señalar los problemas, corresponde describir la arquitectura del Proyecto con algún detalle, porque el diagnóstico cambia según el punto de partida y porque conocer lo que el Proyecto hace bien es necesario para saber dónde buscar los argumentos procesales que habilita.

El Proyecto adopta una estratificación tripartita de riesgo. Los sistemas de bajo riesgo, enumerados en el art. 17, comprenden gestión documental, programación de audiencias, anonimización de resoluciones, transcripción automática voz a texto, traducción, chatbots de atención ciudadana con información general sobre trámites, estadísticas de desempeño y corrección ortográfica. Estos sistemas quedan sujetos a auditoría anual y pueden desplegarse sin procedimiento previo complejo.

Los sistemas de alto riesgo, definidos en el art. 18, son los que asisten funciones críticas de la jurisdicción: interpretación de normas, valoración de pruebas, predicción de resultados de litigios, análisis de jurisprudencia y generación de propuestas de resolución o sentencia. Para estos sistemas el Proyecto exige seis requisitos acumulativos antes del despliegue: Análisis de Impacto Algorítmico favorable, informe favorable de la Comisión de Gobernanza y autorización expresa de la Suprema Corte, implementación de supervisión humana significativa, mecanismos de impugnación accesibles para las partes, registro en el repositorio público de sistemas de IA, y plan de monitoreo continuo. Bajo ninguna circunstancia los sistemas de alto riesgo sustituyen el juicio del juez.

Los sistemas prohibidos o de uso restringido, listados en el art. 19, incluyen ocho categorías que el Proyecto veda absolutamente. Las más relevantes para la práctica: automatización plena de decisiones jurisdiccionales (inc. 1), incluyendo admisibilidad, medidas cautelares, y decisiones de fondo; uso de sistemas que operen sin supervisión humana real y efectiva (inc. 2); herramientas que reproduzcan sesgos discriminatorios por raza, género, origen, religión, condición económica o discapacidad (inc. 3); uso de IA generativa cuyos términos de servicio autoricen al proveedor a usar los datos del usuario para entrenar modelos futuros cuando esos datos incluyan información judicial confidencial (inc. 5); generación de material probatorio sintético (inc. 6); elaboración total o parcial de dictámenes periciales sin la participación activa del perito (inc. 7); y sistemas de predicción de riesgo de reincidencia con efectos vinculantes sobre la libertad personal, salvo norma legal expresa y AIA favorable con auditoría externa independiente (inc. 8).

La prohibición absoluta de automatización jurisdiccional tiene anclaje constitucional directo. El art. 18 de la Constitución Nacional garantiza el juicio previo fundado en ley dictada antes del hecho de la causa, lo que exige razonamiento humano verificable. El art. 1° de la Constitución consagra la forma republicana de gobierno, que requiere responsabilidad de los funcionarios: un funcionario no puede ser responsable por una decisión que no tomó. La prohibición no es solo técnica; es la expresión de un principio constitucional que el Proyecto correctamente recoge.

El repositorio público de sistemas (art. 30) introduce un estándar de rendición de cuentas poco frecuente en el contexto latinoamericano, donde algunos países como Colombia han avanzado en inventarios de sistemas de IA pero con menor nivel de detalle y publicidad. La prohibición de chatbots de uso general en versiones de acceso gratuito para funciones jurisdiccionales (art. 25 inc. 3) es una de las disposiciones más concretas del Proyecto. El deber de declarar el uso de IA en actuaciones que impacten en decisiones sustanciales (art. 29) cierra una brecha que los tribunales de Estados Unidos y los principales órdenes europeos ya están clausurando por vía reglamentaria.

El Proyecto tiene la arquitectura correcta. Los problemas están en los detalles operacionales, y son los detalles los que determinan si una norma tiene dientes o si se convierte en lo que en la literatura especializada se denomina zombie law: citada en los expedientes cuando conviene a alguna parte, ignorada en la práctica, imposible de aplicar e imposible de derogar.

III. EL PROBLEMA CENTRAL: SUPERVISIÓN HUMANA SIN ESTÁNDAR OPERACIONAL

Toda regulación de IA judicial del mundo converge en una misma prescripción: el sistema puede asistir, pero la decisión final corresponde al humano. La supervisión humana es no negociable. El AI Act europeo (Reglamento UE 2024/1689, en vigor desde agosto de 2024) le dedica los arts. 14 y 22 y exige que los despliegues prevean intervención humana efectiva con capacidad de override real sobre los outputs del sistema. El Acuerdo colombiano PCSJA24-12243 de diciembre de 2024 reitera la prescripción. El Proyecto de la SCBA la recoge en el art. 6° como principio rector y en el art. 18 inc. 3 como requisito de despliegue.

El problema es que ninguna de esas normas, incluyendo el AI Act, define operacionalmente cuándo la supervisión es real. Y esa omisión no es inocua.

Para entender por qué, es útil examinar cómo operan estos sistemas en la práctica. Un Large Language Model, que es la arquitectura subyacente de la mayoría de las herramientas de generación de texto jurídico disponibles comercialmente, produce el token estadísticamente más probable dado el contexto de entrenamiento. No razona: optimiza. Cuando se le pide que analice si una cláusula contractual es válida bajo el derecho argentino, el sistema no consulta las normas ni reconstruye la doctrina: genera la secuencia de palabras que, según sus datos de entrenamiento, tiene mayor probabilidad de aparecer en ese contexto. Esa secuencia puede coincidir con el análisis jurídico correcto, y a menudo lo hace. Pero no siempre, y el sistema no tiene mecanismo interno para detectar cuándo su output es correcto y cuándo es plausible pero erróneo.

Esto genera lo que en mi línea de investigación denomino Dynamic Classification Failure (DCF), un modo de falla que propongo como extensión del marco de asimetría de intencionalidad: el operador que supervisa el sistema tiende a atribuirle una capacidad de juicio autónomo que no tiene, porque los outputs del sistema tienen la forma lingüística del razonamiento jurídico correcto. Citan artículos, mencionan jurisprudencia, construyen fundamentos coherentes en su superficie. Esa forma activa en el supervisor los mismos mecanismos cognitivos que activa un colega bien informado. El operador verifica el output con los criterios apropiados para evaluar el razonamiento de un colega, no para evaluar el output de un optimizador estadístico, y esa diferencia es exactamente la que el sistema no puede señalar por sí mismo.

El resultado, bien documentado en contextos médicos, militares y de control de tráfico aéreo desde los años noventa, es el sesgo de automatización: el operador que interactúa repetidamente con un sistema cuyos outputs ha validado sin incidentes detectables tiende a reducir progresivamente el tiempo y la atención dedicados a la revisión. Después de treinta usos sin problemas visibles, la revisión se acelera. Después de cien, es nominal. El magistrado lee el output, lo incorpora al texto de la resolución con mínimas modificaciones de forma, y firma. La supervisión existe en el expediente, no en el proceso cognitivo. El riesgo de error no detectado crece exactamente cuando la confianza en el sistema es mayor.

Este proceso no requiere negligencia ni mala fe. Es la dinámica que la teoría de la evolución aplicada a hábitos de trabajo predice: los comportamientos que no generan consecuencias negativas visibles se consolidan porque consumen menos recursos cognitivos, y los que consumen tiempo sin aparente beneficio diferencial se eliminan. La supervisión sustantiva es costosa. La supervisión formal, no.

El Proyecto menciona el sesgo de automatización en el considerando 6° de la Resolución pero no lo operacionaliza en ninguna norma del articulado. La consecuencia es que el art. 6° exige supervisión humana significativa sin que ninguna disposición del Proyecto permita determinar, en un caso concreto, si esa supervisión se satisfizo o no.

Para el abogado litigante esto tiene una implicación directa: cuando el Proyecto sea vinculante, si una resolución judicial incorpora un análisis jurídico generado con IA, la pregunta procesalmente relevante no es si el magistrado usó un sistema de IA, sino si puede demostrar que ejerció supervisión sustantiva sobre ese output. El art. 26 inc. 6 del Proyecto le impone verificar toda cita normativa o jurisprudencial producida por el sistema en fuente primaria antes de incorporarla a cualquier actuación. Un magistrado que firmó una resolución con una cita jurisprudencial errónea generada por un LLM, sin haberla verificado en el texto completo del fallo, no satisface ese estándar. Eso es impugnable, y la impugnación tiene base normativa en el propio Proyecto.

El estándar que la versión definitiva del Proyecto debería establecer, y que fue propuesto en la consulta pública, incluye al menos tres elementos acumulativos: verificación independiente de cada cita normativa o jurisprudencial en fuente primaria antes de incorporarla; documentación del proceso de revisión que indique qué partes del output fueron aceptadas, modificadas o rechazadas, y por qué; y capacidad del operador de exponer el razonamiento esencial que sustenta la actuación sin asistencia del sistema. La mera lectura del output sin verificación no satisface ese estándar. La firma de un documento que el operador no comprende íntegramente, tampoco.

IV. EL PERITO QUE FIRMA LO QUE NO COMPRENDE: GARANTÍA DE CONTRADICCIÓN Y PROCESO ORAL

El art. 19 inc. 7 del Proyecto prohíbe el uso de IA para elaborar dictámenes periciales sin la participación activa del perito habilitado. Define esa participación activa como cuatro elementos: validación de la metodología empleada por el sistema, evaluación crítica de los resultados, asunción personal de las conclusiones, y suscripción con firma y sello profesional.

La definición tiene un hueco técnico que los litigantes deberían conocer.

Tal como está redactada, la norma permite que un perito genere con IA la totalidad del razonamiento técnico del dictamen, revise superficialmente el output, lo suscriba con firma y sello, y cumpla formalmente todos los requisitos enumerados. La norma no exige que el perito sea capaz de reproducir independientemente el razonamiento que sustenta cada conclusión. Puede validar una metodología que no comprende en profundidad, evaluar críticamente un resultado que no puede explicar sin el sistema, y asumir personalmente conclusiones cuya fundamentación técnica reside en una caja negra algorítmica.

En el proceso oral bonaerense eso tiene consecuencias concretas. El art. 474 del Código Procesal Civil y Comercial de la Provincia de Buenos Aires establece que el perito puede ser interrogado en audiencia por las partes y por el tribunal. La garantía de contradicción consagrada en el art. 18 de la Constitución Nacional exige que las partes puedan confrontar efectivamente la prueba en su contra. En materia pericial, eso significa la posibilidad real de interrogar al experto sobre el razonamiento que lo llevó a cada conclusión, no solo sobre la conclusión misma.

Si el perito utilizó un sistema de IA para generar ese razonamiento y no comprende el modelo que lo produjo, el interrogatorio en audiencia expone la situación con precisión: el perito puede explicar qué instrucción le dio al sistema y qué output obtuvo, pero no puede explicar por qué el sistema llegó a esa conclusión y no a otra, qué factores del caso concreto determinaron el resultado, qué pasaría si uno de esos factores cambiara, ni si el resultado se mantendría bajo condiciones levemente distintas. El perito puede recitar la conclusión. No puede defender el razonamiento.

Esa situación habilita, según las circunstancias del caso, al menos dos líneas de ataque procesal. La primera es la impugnación del dictamen por insuficiencia técnica: si el perito no puede explicar el razonamiento que sustenta sus conclusiones, el dictamen no satisface los requisitos de fundamento que el art. 474 CPCCBA exige implícitamente y que la doctrina procesal bonaerense ha desarrollado en el sentido de que el dictamen debe ser suficientemente explicativo para permitir su control por las partes. La segunda es la solicitud de exclusión de las conclusiones específicas que el perito no puede defender: no necesariamente del dictamen entero, sino de aquellas conclusiones cuya fundamentación descansa en razonamiento algorítmico opaco.

Ninguna de estas estrategias tiene garantía de prosperar. No hay todavía una línea jurisprudencial consolidada sobre impugnación de dictámenes asistidos por IA, ni en Argentina ni en el derecho comparado, precisamente porque el fenómeno es reciente. Pero el argumento existe, y la solidez de ese argumento aumenta después de que el Proyecto sea vinculante, porque el perito que firma sin comprender habrá incumplido la norma expresa que exige participación activa.

El aporte presentado en la consulta pública propone que la versión definitiva del art. 19 inc. 7 agregue un requisito: la participación activa incluye la capacidad del perito de exponer y defender el razonamiento técnico esencial que sustenta cada conclusión sin asistencia del sistema de IA durante el interrogatorio en audiencia. Si esa propuesta prospera, el estándar queda fijado por la norma. Si no prospera, el argumento procesal existe igualmente, pero deberá construirse sobre la garantía constitucional de contradicción en lugar de sobre el texto expreso del reglamento.

V. DATOS DE LA CAUSA, LEY 25.326 Y LA EXPOSICIÓN DEL ABOGADO

El art. 28 del Proyecto prohíbe a los operadores judiciales introducir en herramientas de IA generativa de acceso comercial datos personales, información confidencial de las partes, datos de investigaciones en curso, o cualquier otro dato sensible, cuando los términos de servicio del proveedor autoricen el uso de esos datos para reentrenar modelos futuros o para el acceso de terceros. La prohibición aplica a magistrados, funcionarios y auxiliares de la justicia. No aplica directamente a los abogados en ejercicio.

La Ley 25.326 de Protección de los Datos Personales sí aplica a todos.

La Ley 25.326 establece un régimen de tres categorías con consecuencias jurídicas sustancialmente distintas. Los datos sensibles, definidos en el art. 2 in fine como aquellos que revelan origen racial y étnico, opiniones políticas, convicciones religiosas o morales, afiliación sindical, e información sobre salud y vida sexual, tienen el régimen más restrictivo: su tratamiento está prohibido como regla general, con excepciones taxativas (art. 7 inc. 1). Los datos relativos a infracciones penales, condenas y sospechas de delitos tienen un régimen especial (art. 7 inc. 3) que los equipara funcionalmente a los datos sensibles en cuanto al nivel de protección. Los datos personales ordinarios, toda información concerniente a personas físicas o jurídicas determinadas o determinables (art. 2), pueden tratarse bajo las condiciones generales del art. 5, que requieren en principio el consentimiento libre, expreso e informado del titular.

El Proyecto de la SCBA trata esas tres categorías de manera uniforme en sus prohibiciones, sin distinguir los regímenes que la ley especial establece. Eso genera dos problemas prácticos para el abogado.

El primero es la ambigüedad sobre qué está prohibido en cada caso. Una consulta abstracta sobre el régimen jurídico de una cláusula de no competencia no contiene datos personales. Una consulta que menciona el número de expediente, la identidad de las partes o las circunstancias del caso ya los contiene. ¿Dónde está el límite? El Proyecto no lo define, lo que genera incentivos a la evasión informal: el operador que quiere usar la herramienta aprende a formular consultas sin mencionar identificadores directos, que es exactamente el comportamiento que la norma intentaba prevenir y que además puede no ser suficiente para proteger la privacidad, porque la combinación de datos aparentemente anonimizados puede permitir la re-identificación.

El segundo problema es la falta de una vía lícita para el uso con datos ordinarios. Las técnicas de anonimización diferencial permiten preservar las propiedades estadísticas de un conjunto de datos sin exponer registros individuales. Un operador que anonimiza adecuadamente los datos antes de ingresarlos en una herramienta de IA podría argumentar que no está transfiriendo datos personales en sentido técnico. El Proyecto actual no reconoce esa posibilidad, lo que bloquea usos potencialmente lícitos y útiles.

Para el abogado en ejercicio el punto crítico es independiente del Proyecto: la Ley 25.326 ya aplica. El abogado que ingresa en una herramienta de IA comercial, sea ChatGPT, Gemini, Copilot, o cualquier servicio cuya política de privacidad no garantice aislamiento total del procesamiento, información que identifica a su cliente, a la contraparte, o a testigos en una causa en trámite, está ejecutando una transferencia de datos personales a un tercero. Esa transferencia requiere consentimiento informado del titular (art. 5 Ley 25.326) o que encuadre en alguna de las excepciones del art. 5 inc. 2, ninguna de las cuales aplica mecánicamente al uso de IA en la práctica jurídica ordinaria.

Las consecuencias son tres. Primera: exposición a sanciones administrativas ante la Dirección Nacional de Protección de Datos Personales bajo el art. 31 de la ley, que incluyen desde el apercibimiento hasta la suspensión de la actividad según el procedimiento que corresponda. 31 de la ley, incluyendo suspensión de la actividad de archivos o bases de datos. Segunda: exposición a acción civil del cliente por responsabilidad profesional (arts. 1724 y concordantes del CCyCN). Tercera: exposición a consecuencias disciplinarias ante el colegio de abogados correspondiente, que tiene atribuciones para sancionar conductas que vulneren la confidencialidad de la relación cliente-abogado.

La regla práctica es más simple que el régimen legal: si el dato permite identificar a una persona física o jurídica en relación con un asunto en trámite, no pertenece en ninguna herramienta cuya política de privacidad no garantice expresamente que esos datos no serán utilizados para ningún propósito distinto del requerimiento inmediato del usuario. Esa garantía no existe en los planes gratuitos ni en la mayoría de los planes comerciales de los grandes proveedores. Verificarlo antes de usar la herramienta con datos de clientes no es una precaución excesiva: es el estándar de diligencia que la Ley 25.326 ya exige.

VI. EL RÉGIMEN DE RESPONSABILIDAD CIVIL: QUIÉN RESPONDE CUANDO EL SISTEMA FALLA

El Proyecto tiene una laguna que tiene consecuencias directas para el litigante: no define el régimen de responsabilidad civil cuando un sistema de IA de alto riesgo contratado a un proveedor externo produce un error que genera daño a las partes.

La Resolución RSC-1719-2026 menciona en su art. 6° "la responsabilidad que pudiere corresponder al proveedor de la herramienta conforme la normativa aplicable", sin desarrollar ese punto. El art. 12 inc. 6 del Proyecto exige que los contratos con proveedores incorporen cláusulas de cumplimiento de los lineamientos del reglamento, pero no especifica cuáles son esas cláusulas mínimas ni cómo se distribuye el riesgo entre la Suprema Corte y el proveedor.

El Código Civil y Comercial de la Nación establece en los arts. 1757 y 1758 la responsabilidad objetiva por actividad riesgosa. El art. 1757 dispone que toda persona responde por el daño causado por el riesgo o vicio de las cosas, o de las actividades que sean riesgosas o peligrosas por su naturaleza, por los medios empleados, o por las circunstancias de su realización, y que esa responsabilidad es objetiva. El art. 1758 establece que el dueño y el guardián son responsables concurrentes, y que guardián es quien ejerce la guarda de la cosa.

La cuestión no resuelta en ningún caso argentino publicado es quién asumiría el carácter de guardián cuando la Suprema Corte despliega un sistema de IA de alto riesgo contratado a un proveedor externo. Lo que sigue es una lectura doctrinaria del CCyCN aplicada a ese escenario hipotético. El guardián, en términos del art. 1758, es quien ejerce el uso, la dirección y el control de la cosa. En un modelo de contratación de IA como servicio, el proveedor mantiene el control sobre la arquitectura del modelo, los datos de entrenamiento, los parámetros del sistema, y los ciclos de actualización. La Suprema Corte accede a los resultados a través de una interfaz, sin control sobre el modelo subyacente.

Si el proveedor es el guardián en términos del art. 1758, responde objetivamente por los daños causados por el vicio o riesgo del sistema. Si la Suprema Corte es la guardián porque contrató el servicio para sus propios fines, responde ella, y la responsabilidad del proveedor quedará determinada por las cláusulas contractuales. En ausencia de cláusulas contractuales que distribuyan específicamente el riesgo, la determinación de quién responde frente a las partes dañadas requiere litigio.

Para el abogado que representa a una parte que alega haber sufrido un daño derivado de una decisión judicial asistida por un sistema de IA que produjo un error, ese litigio de responsabilidad no tiene jurisprudencia establecida en Argentina. Pero el marco legal existe, la responsabilidad objetiva del art. 1757 es aplicable en principio, y la pregunta sobre la guarda del sistema es la que determina quién la soporta.

Adicionalmente, el art. 1726 del CCyCN establece que son reparables las consecuencias dañosas que tienen nexo adecuado de causalidad con el hecho productor del daño. Si una resolución judicial incorporó un análisis erróneo generado por un sistema de IA, y ese análisis determinó el sentido de la resolución, y la resolución causó un daño a la parte que obtuvo un resultado adverso fundado en ese error, el nexo causal existe. La acción de responsabilidad del Estado por actividad judicial es de construcción jurisprudencial compleja y con obstáculos procesales importantes, pero el fundamento sustantivo no está ausente.

VII. EL DERECHO COMPARADO: LO QUE LOS DEMÁS YA RESOLVIERON

El Proyecto de la SCBA no surgió en el vacío. Sus propios considerandos citan tres instrumentos internacionales que permiten una comparación precisa.

El AI Act europeo (Reglamento UE 2024/1689) es el instrumento más desarrollado. Clasifica los sistemas de IA que asisten a órganos judiciales en la aplicación del derecho como de alto riesgo (Anexo III, punto 8) y establece para ellos un régimen de obligaciones que el Proyecto de la SCBA recoge solo parcialmente. El AI Act exige documentación técnica detallada (art. 11), registros automáticos de eventos durante el funcionamiento (art. 12), información a los usuarios sobre las capacidades y limitaciones del sistema (art. 13), supervisión humana con mecanismos de override efectivo que no puedan ser deshabilitados (art. 14), precisión y robustez verificables con umbrales definidos (art. 15), y evaluación de conformidad por organismos notificados independientes antes del despliegue (arts. 43-44).

El punto de mayor divergencia entre el AI Act y el Proyecto de la SCBA está en la evaluación de conformidad. El AI Act exige que para sistemas de alto riesgo, la evaluación sea realizada por un organismo notificado externo e independiente cuando el proveedor no puede demostrar de manera fidedigna que sus propias evaluaciones son objetivas. El Proyecto de la SCBA, en su art. 20, exige un AIA favorable pero no establece quién lo realiza, con qué metodología, ni cuál es el umbral de aprobación. El art. 18 inc. 1 exige AIA favorable como requisito de despliegue sin definir qué lo hace favorable. En ausencia de esa definición, el AIA tiende a convertirse en un ejercicio de autovalidación del proveedor que ningún organismo interno está en condiciones técnicas de objetar. Un proveedor que elabora su propio AIA, lo presenta como favorable, y la Comisión lo aprueba por falta de criterios independientes de evaluación, no es el régimen de control que el art. 20 pretende instaurar.

El Acuerdo colombiano PCSJA24-12243, aprobado por el Consejo Superior de la Judicatura en diciembre de 2024, es el antecedente regional más próximo y el más instructivo para evaluar el Proyecto bonaerense. Colombia adoptó un sistema de clasificación similar, con prohibiciones equivalentes y principios análogos. La diferencia clave está en el tratamiento de la supervisión humana: el instrumento colombiano pone mayor énfasis en la documentación activa del proceso de supervisión como condición de su efectividad, una distinción que el Proyecto argentino enuncia a nivel de principios pero no operacionaliza en el articulado. El Proyecto argentino enuncia el principio de supervisión humana pero no crea ningún mecanismo para distinguir, en un caso concreto, si ese principio fue satisfecho.

Las Directrices de UNESCO para el Uso de Sistemas de IA en Cortes y Tribunales (2026), citadas en los propios considerandos del Proyecto, establecen un conjunto de principios entre los que se cuentan que incluyen precisión y fiabilidad, explicabilidad, auditabilidad, transparencia, responsabilidad, y supervisión humana significativa. El Proyecto de la SCBA los recoge con fidelidad razonable a nivel de enunciados. El rezago está en el nivel de los mecanismos: los principios existen en el articulado, los instrumentos para verificar su cumplimiento, no.

La lectura comparada permite una conclusión que no es condena sino diagnóstico: el Proyecto de la SCBA está al nivel del estándar internacional en arquitectura y principios, y rezagado respecto de los instrumentos más avanzados en el nivel de los mecanismos operativos de control. Eso es exactamente lo que una consulta pública todavía puede modificar.

VIII. IMPLICACIONES PARA EL ESTUDIO JURÍDICO COMO ORGANIZACIÓN

Las implicaciones del Proyecto no se limitan al litigante individual. El estudio jurídico que adopta herramientas de IA en su práctica cotidiana enfrenta un conjunto de decisiones organizacionales que el Proyecto ilumina, aunque no regula directamente.

El primer problema organizacional es el de la política de uso interno. Un estudio que permite a sus asociados usar herramientas de IA de acceso comercial para preparar escritos, analizar jurisprudencia, o generar borradores de contratos, sin una política explícita sobre qué datos pueden ingresarse en esas herramientas, está operando en exposición. La Ley 25.326 no distingue entre el abogado individual y el estudio como organización cuando se trata de responsabilidad por transferencia de datos personales. Si el asociado ingresó datos de clientes en una herramienta de IA sin el consentimiento del cliente y sin que el estudio tuviera una política al respecto, la responsabilidad puede extenderse al estudio.

El segundo problema organizacional es el del estándar de verificación. Un estudio que usa IA para generar análisis jurídicos, citas de jurisprudencia o fundamentos de escritos, y presenta esos productos ante tribunales sin una política de verificación sistemática en fuente primaria, está creando un riesgo de responsabilidad profesional. El art. 26 inc. 6 del Proyecto establece el estándar para los operadores judiciales. Para los abogados litigantes, ese estándar marca el nivel que el tribunal va a esperar de cualquier operador del foro. Un escrito presentado con una cita jurisprudencial inexacta generada por IA, en un foro donde el reglamento ya está en vigor, es un problema diferente a lo que habría sido ese mismo error hace dos años.

El tercer problema organizacional es el de la gestión de peritos. El estudio que trabaja con peritos que usan IA en sus dictámenes necesita saber, antes de presentar ese dictamen, si el perito puede defenderlo en audiencia. La pregunta no es si el perito usó IA, que en sí mismo no está prohibido. La pregunta es si el perito comprende el razonamiento que sustenta cada conclusión con independencia del sistema. Un estudio que no hace esa verificación antes de presentar el dictamen está delegando en el perito una evaluación que puede tener consecuencias procesales costosas.

IX. EL RÉGIMEN TRANSITORIO QUE NO EXISTE: ZONA GRIS DESDE EL DÍA UNO

El Proyecto no contempla qué ocurre con los sistemas de IA que estén siendo utilizados al momento en que adquiera carácter vinculante. No habrá una lista de sistemas autorizados por la Comisión de Gobernanza el día uno. No habrá AIA aprobados para las herramientas en uso al momento de la vigencia. No habrá ningún sistema formalmente clasificado hasta que la Comisión, creada por el art. 4° de la Resolución, elabore el diagnóstico previsto en el art. 9° inc. a) del Proyecto, que puede tardar meses.

Los operadores que utilizan hoy sistemas de IA en sus funciones, con o sin conocimiento de su categorización de riesgo según los criterios del Proyecto, quedarán en situación jurídica indeterminada desde el primer día de vigencia del reglamento definitivo. El art. 6° de la Resolución establece que el uso de herramientas de IA no exime de responsabilidad al operador por el contenido, validez y legalidad de los actos en los que aquellas hubieren intervenido. Si el operador usó un sistema no clasificado, no autorizado, no evaluado mediante AIA, ¿ese uso genera responsabilidad? El Proyecto actual no lo aclara.

El aporte presentado en la consulta pública sobre este punto propone incorporar una disposición transitoria que establezca un plazo no inferior a seis meses desde la vigencia del reglamento definitivo para que la Comisión clasifique los sistemas en uso y elabore el catálogo de herramientas autorizadas. Sin esa disposición, el día uno del reglamento vinculante es también el día uno de una zona gris regulatoria que puede durar meses.

Para el abogado litigante, la ausencia de régimen transitorio crea una ventana de impugnación que vale la pena conocer. Cualquier actuación judicial producida con asistencia de un sistema de IA no clasificado por la Comisión durante el período que corre entre la vigencia del reglamento y la elaboración del catálogo podría ser cuestionada, al menos argumentativamente, por ese defecto formal. La impugnación tiene un límite: para prosperar, requeriría demostrar que el uso del sistema no clasificado causó un perjuicio concreto a la parte que impugna, no solo que existió un incumplimiento formal. Pero el argumento existe, y en un litigio de alta intensidad, el argumento que existe se usa.

X. LA LECTURA DE FONDO: POR QUÉ LOS REGLAMENTOS DE IA SE CONVIERTEN EN ZOMBIE LAW

El Proyecto de la SCBA puede analizarse no solo como instrumento normativo sino como caso de diseño institucional bajo incertidumbre tecnológica. Los sistemas de IA evolucionan más rápido que los ciclos legislativos. Un reglamento aprobado en junio de 2026 sobre sistemas de IA que existen hoy regulará, en su versión definitiva, sistemas que serán significativamente más capaces, más integrados, y más opacos. Ese desfasaje estructural es el problema de fondo que ningún reglamento del mundo ha resuelto todavía.

La distinción entre supervisión formal y sustantiva es el punto donde esa tensión se manifiesta con mayor claridad. Un reglamento que enuncia supervisión humana pero no la operacionaliza no desaparece: se convierte en zombie law. La norma sobrevive formalmente, se cita en los expedientes cuando conviene, pero nadie puede incumplirla porque nadie puede controlar su cumplimiento, y nadie puede derogarla porque es técnicamente vigente. El considerando de la resolución que menciona el sesgo de automatización, pero que no tiene correlato en el articulado, es el prototipo de ese proceso.

La teoría del fenotipo extendido aplicada al derecho sugiere que los reglamentos compiten por adaptación en el ambiente institucional donde se despliegan. El Proyecto compite con al menos tres fenotipos alternativos que ya operan: el de adopción informal sin regulación (vigente hasta el 19 de junio), el de prohibición total sin implementación real, y el de declaración de principios sin mecanismos operativos. El fitness del Proyecto en ese ambiente competitivo depende de si logra operacionalizar sus principios antes de que los operadores desarrollen rutinas que satisfagan la letra de la norma sin satisfacer su espíritu.

Esa operacionalización es exactamente lo que la consulta pública, que cierra el 7 de agosto, todavía puede incorporar.

XI. QUÉ HACER ANTES DEL 7 DE AGOSTO de 2026

La consulta pública cierra el 7 de agosto de 2026. El formulario está disponible en www.scba.gov.ar. Los aportes se canalizan por bloques temáticos que corresponden a los capítulos del Proyecto. No hay restricciones sobre quién puede presentar observaciones: magistrados, funcionarios, abogados, colegios profesionales, instituciones académicas y demás interesados están expresamente habilitados por el art. 2° de la Resolución RSC-1719-2026.

Para el abogado que ya usa IA en su práctica, las implicaciones del Proyecto son inmediatas en tres frentes: revisar la política de uso de herramientas de IA en el estudio respecto de datos de clientes y actualizar los contratos de prestación de servicios para incluir cláusulas de consentimiento informado para el uso de IA; verificar con los peritos de confianza si están en condiciones de defender en audiencia los dictámenes que generan con asistencia de sistemas de IA; y documentar los procesos de verificación de citas y análisis generados con IA, no solo el resultado final, de modo de poder demostrar supervisión sustantiva si se requiere.

Para el abogado que litiga ante el fuero bonaerense, las implicaciones sobre el material producido por la contraparte o por el tribunal son igualmente relevantes: cualquier actuación judicial asistida por IA que no pueda demostrar verificación independiente de sus citas, o cualquier dictamen pericial cuyo firmante no pueda defender el razonamiento en audiencia, tiene un vector de impugnación que el Proyecto, en su versión actual o definitiva, abre.

Los textos completos de los aportes presentados en la consulta pública, con las redacciones propuestas para cada artículo, están disponibles en adrianlerer.substack.com.