Construir en público sin exponer a nadie
Un repositorio abierto puede mostrar cómo se construye una herramienta jurídica sin publicar los problemas de personas reales. Estas son las reglas de privacidad que aplicamos y el error de historial que corregimos antes de abrir el proyecto.
Construir una herramienta jurídica en público tiene un conflicto difícil de esquivar: el método puede ser abierto, pero los problemas de los clientes no. Secreto profesional, datos personales, estrategias de negociación y detalles procesales conviven con un repositorio que cualquiera debería poder examinar.
Nuestra respuesta no es prometer que la privacidad aparece por usar una aplicación local. Es separar datos y método con reglas que se puedan revisar, y contar qué hicimos cuando descubrimos que una de esas reglas no alcanzaba.
Los casos reales no entran al repositorio#
El contenido público se prueba primero con casos sintéticos. Si un ejemplo real aporta algo que no se puede reproducir de otro modo, se transforma antes de usarlo: no basta con sustituir el nombre por [CLIENTE]. También se alteran los hechos que podrían volver identificable a la persona cuando se los combina.
La regla se aplica antes de abrir el asistente, incluso cuando la interfaz corre en la computadora del abogado. Local no significa que el contexto permanezca local. Si la tarea utiliza un modelo o una API externa, la información necesaria para responder viaja al proveedor. Lo mismo puede ocurrir con una búsqueda semántica o con un conector, según la arquitectura elegida.
Por eso la unidad de control no es solamente el archivo que termina en GitHub. También son el prompt, los documentos adjuntos, la consulta de búsqueda y cada herramienta que recibe parte del contexto.
La configuración personal vive fuera de git#
La identidad del profesional, su matrícula, sus rutas de trabajo y otras preferencias personales viven en legal.local.md. El archivo está excluido por .gitignore; el repositorio solo incluye una plantilla vacía.
Eso reduce el riesgo de versionar datos por accidente y permite que otro estudio adopte el mismo método sin heredar la identidad del anterior. Pero el alcance del control debe quedar claro: .gitignore evita que el archivo entre al repositorio; no evita que su contenido sea enviado al proveedor si una sesión lo carga. La configuración local también debe contener el mínimo necesario.
El nombre del producto no responde la pregunta de privacidad#
Las condiciones de tratamiento cambian según el plan, la organización, la vía de acceso, el modelo y las integraciones. En la documentación de Anthropic consultada el 30 de agosto de 2026, por ejemplo, Zero Data Retention (ZDR) no aparece como una propiedad general de usar Claude: se habilita para organizaciones elegibles y cubre productos o superficies determinados. La misma documentación advierte que ciertos Covered Models pueden requerir una retención de 30 días incluso para organizaciones con ZDR.
Un conector externo agrega otra frontera: parte del contexto puede llegar a un tercero con sus propios términos. Decir "usamos Claude" o "tenemos ZDR" no describe por sí solo el recorrido de los datos.
La revisión correcta tiene que responder, como mínimo, estas preguntas:
- ¿Qué información sale de la computadora o de la infraestructura del estudio?
- ¿Qué proveedor o tercero la recibe en cada paso?
- ¿Qué retención, contrato y modelo aplican a ese flujo concreto?
El error estaba en la película, no en la foto#
Durante la etapa privada del proyecto detectamos rutas de disco y referencias internas que no debían quedar versionadas. Los archivos actuales se sanearon. Parecía suficiente hasta revisar el problema con la pregunta completa: ¿qué conserva el historial?
Git no olvida un dato porque desaparezca de la última versión. Si un commit anterior lo contiene, ese dato sigue en la historia alcanzable del repositorio. Antes de la apertura pública, republicamos el proyecto desde un commit inicial limpio y convertimos la revisión del historial en un bloqueo de publicación.
La diferencia es sencilla: el árbol de trabajo es una foto; el historial es la película. La auditoría de privacidad necesita revisar ambos.
El 30 de agosto de 2026 repetimos el control sobre un clon nuevo del repositorio público, en el commit e25d6be. El verificador no encontró coincidencias en los 172 archivos del árbol actual ni en los 219 archivos examinados al recorrer el historial alcanzable. Es una evidencia fechada y reproducible, no una garantía de riesgo cero.
Un control que se puede volver a ejecutar#
El repositorio incluye scripts/check_sensitive.py, un control que revisa patrones sensibles antes de publicar. Puede examinar los archivos actuales con --all y recorrer el historial con --history. El equipo mantiene además patrones privados fuera del repositorio público para detectar datos propios sin revelar cuáles son.
El script no reemplaza el criterio humano. Un nombre puede faltar en la lista, y una combinación de hechos puede identificar a alguien sin contener un dato obvio. Por eso el proceso suma varias capas: casos sintéticos primero, anonimización por sustitución y alteración, archivos personales excluidos, commits pequeños y revisión del historial desde un clon limpio.
La Ley 7593 como estándar de diseño anticipado#
La Ley N.º 7593/2025 de Protección de Datos Personales fue publicada el 27 de noviembre de 2025. Su artículo 57 dispone la entrada en vigencia a los 24 meses de la publicación; por eso, salvo un cambio normativo, entrará en vigor el 27 de noviembre de 2027. El artículo 60 fija el mismo plazo para la reglamentación.
Dikaia adopta desde ahora sus principios como estándar de diseño y está adecuando sus términos, políticas y prácticas a la norma antes de su entrada en vigor. Esto no significa afirmar que la ley ya está vigente ni presentar una arquitectura técnica como certificación de cumplimiento. Significa no esperar hasta 2027 para minimizar datos, documentar finalidades y hacer visibles los recorridos de información.
Por qué hacemos público el tropiezo#
La confianza en una herramienta jurídica no debería depender de que su proveedor solo muestre aciertos. También importa saber qué error encontró, cómo cambió el proceso y qué evidencia permite verificar la corrección.
En este caso, borrar las referencias de la versión actual no bastaba. La medida correcta fue limpiar antes de abrir, revisar la historia completa y dejar un control repetible para las próximas publicaciones. El método abierto sirve justamente para eso: no para exponer datos, sino para volver examinables las decisiones que los protegen.
Fuentes consultadas#
- Ley N.º 7593/2025, texto oficial en la BACN, especialmente arts. 57 y 60.
- Ficha legislativa oficial de la Ley N.º 7593/2025, con fecha de publicación del 27/11/2025.
- Alcance de Zero Data Retention, documentación de Anthropic.
- Retención aplicable a Covered Models, documentación de Anthropic.
- Integraciones y flujos hacia terceros, documentación de Anthropic.
- Claude for Legal Paraguay, repositorio público y controles de seguridad reproducibles.
Revisá el recorrido de tus datos, no solo la interfaz#
El método completo está disponible en Claude for Legal Paraguay. En GNOSIS y su asistente Kai aplicamos la misma idea: documentar qué entra, qué sale y qué control existe en cada frontera.
Si estás evaluando una herramienta de IA para tu estudio, pedile al proveedor una respuesta concreta sobre el recorrido, los destinatarios y la retención de tus datos. La claridad de esa respuesta también forma parte del producto.
Artículos relacionados
Evals jurídicos: si una skill falla un caso, no se publica
Hay una pregunta que desnuda a cualquier producto de IA jurídica: cómo sabés que funciona. Lo probamos y responde bien no alcanza, porque es una anécdota. Nuestra respuesta es una regla escrita: cada materia tiene casos de prueba, y si una skill falla un caso importante no se publica.
Robar el patrón, nunca el contenido
La tentación obvia era clonar algo que ya funcionara. Estudiamos los dos mejores candidatos hasta entenderlos, tomamos sus patrones de diseño y no copiamos una sola afirmación jurídica de ninguno. Esa distinción entre patrón y contenido terminó siendo una de las decisiones más importantes del proyecto.
El authority map: separar el derecho del prompt
Si le pedís a cualquiera que configure un GPT jurídico, va a escribir un prompt largo con las leyes adentro. Funciona una semana. Nosotros tomamos la decisión inversa: el prompt define el método y el derecho vive en datos estructurados, con ciclo de vida, bitácora y un validador que rompe el build.