Cumplimiento IA & Auditoría | Arquitectura Rust Certificable | Lexiane

Las exigencias de cumplimiento aplicables a los sistemas de inteligencia artificial se endurecen. IEC 62304 Ed. 2, ISO 26262, DORA, NIS2, RGPD, AI Act: los referenciales se acumulan, sus perímetros se solapan, y los plazos se estrechan. La mayoría de las organizaciones que buscan desplegar IA en entorno regulado se enfrentan a la misma realidad: las soluciones disponibles fueron concebidas para otros contextos, y el cumplimiento se trata en ellas como una capa a añadir a posteriori — un proceso documental sobre un sistema que no lo hace posible por naturaleza.

Lexiane está concebido en el orden inverso. El cumplimiento no es una funcionalidad. Es la consecuencia directa de un conjunto de decisiones arquitecturales tomadas desde las primeras líneas de código.

---

La IA regulada: lo que sus auditores van a buscar — y lo que la mayoría de los sistemas no puede proporcionarles

Un auditor que trabaja sobre un sistema IA en entorno regulado plantea invariablemente las mismas preguntas fundamentales.

Trazabilidad. ¿Quién decidió qué, sobre qué base, en qué momento? Para un sistema de procesamiento documental o de generación de respuestas, esto significa: ¿qué documento fue ingerido, por qué pipeline, con qué parámetros? ¿Qué decisión de filtrado se aplicó, sobre qué dato? ¿Qué respuesta se produjo, a partir de qué fuentes?

Aislamiento de los componentes terceros. En los referenciales IEC 62304 e ISO 26262, un componente software cuyo código fuente no está íntegramente controlado por el fabricante se clasifica como SOUP — Software of Unknown Provenance. El SOUP debe ser identificado, documentado, y su interfaz con el sistema certificado debe estar explícitamente delimitada. En un sistema Python típico, esta frontera es estructuralmente imposible de trazar: las bibliotecas se importan mutuamente, las dependencias transitivas son numerosas, y la línea entre código controlado y código SOUP es difusa por naturaleza.

Determinismo y ausencia de comportamiento indefinido. Un sistema certificado debe comportarse de forma previsible. Un garbage collector que desencadena una pausa en un momento crítico, un bug de tipo enmascarado por el tipado dinámico de Python, una dependencia implícita entre dos módulos — cada uno de estos fenómenos es una fuente de comportamiento no determinista que un auditor no puede aceptar sin compensación.

Soberanía de los datos. En los entornos regulados — defensa, salud, finanzas, sector público —, la cuestión de la localización de los datos no es una preferencia. Es una exigencia regulatoria u operacional cuyo incumplimiento expone a la organización a sanciones, responsabilidades, o riesgos soberanos.

Lexiane ha sido concebido para responder a estas cuatro exigencias — no por declaración, sino mediante mecanismos verificables a la inspección del código y de la arquitectura.

---

Una arquitectura cuyas propiedades de cumplimiento están probadas en la compilación

El perímetro certificado: un núcleo sin concesiones

El núcleo de Lexiane — vectrant-core — está sometido a una restricción absoluta: #![forbid(unsafe_code)]. Esta directiva no es una convención de desarrollo ni una regla de revisión de código. La aplica el propio compilador Rust. Ningún desarrollador puede introducir una operación de memoria no verificada en el perímetro certificado, ni siquiera inadvertidamente, ni siquiera bajo presión — el compilador rechaza el código antes de que exista el binario.

En este perímetro, las siguientes propiedades están garantizadas mecánicamente:

• Ausencia de punteros nulos: los valores opcionales se expresan mediante Option<T>, cuyo tratamiento es exhaustivo y verificado en la compilación.
• Ausencia de fugas de memoria y de use-after-free: el sistema de propiedad de Rust elimina estas categorías de bugs por construcción — sin garbage collector, sin runtime adicional.
• Ausencia de caminos de error ignorados: el marcador #[must_use] se aplica sobre la totalidad de los resultados. Un camino de error no tratado es un error de compilación, no un bug descubierto en pruebas o en producción.
• Ausencia de unwrap(), expect() o panic!() en código de producción: verificado por un test automatizado en integración continua. Cualquier regresión se detecta inmediatamente.

Lo que esto representa para un auditor: un perímetro cuyas propiedades de seguridad están probadas en la compilación, independientemente de las prácticas de los desarrolladores individuales.

El aislamiento del SOUP: una frontera arquitectural, no documental

Lexiane está estructurado según una arquitectura hexagonal estricta. El núcleo certificado se comunica con el mundo exterior exclusivamente a través de 25 interfaces de abstracción tipadas — contratos de interfaz explícitos, verificados estáticamente. Ninguna dependencia externa puede penetrar en el núcleo sin pasar por una de estas interfaces.

Los componentes terceros — modelos de lenguaje, bases vectoriales, parsers de documentos, APIs cloud — son adaptadores que implementan estas interfaces. Son íntegramente clasificables como SOUP, con una frontera arquitectural neta y verificable: la lista de interfaces. Lo que está dentro está controlado. Lo que está fuera está documentado y aislado.

Una restricción complementaria refuerza esta separación: el núcleo certificado no contiene cero dependencias de proveedor — verificado por un test automatizado que falla en la compilación si se introduce una dependencia externa. Este test forma parte de la suite de integración continua: la regresión es imposible sin que sea detectada inmediatamente.

La validación estática de las dependencias entre componentes

El pipeline de Lexiane valida sus dependencias internas en el ensamblado, antes de cualquier ejecución. Cada etapa declara los datos que consume y los datos que produce. El ensamblador verifica estáticamente que el conjunto de las dependencias está satisfecho antes de que el pipeline arranque.

Para un auditor, esto significa que un error de configuración — una etapa faltante, una dependencia no satisfecha, un componente mal conectado — no es un bug que aparece en la ejecución sobre un dato real. Es un error de ensamblado detectado antes de que el sistema trate un único documento.

---

Conformidad RGPD: la protección de datos por arquitectura

La residencia de datos como propiedad física

El RGPD impone una localización de los datos personales en condiciones que el responsable del tratamiento puede controlar y documentar. La mayoría de las soluciones IA cloud satisfacen esta exigencia por contrato: una cláusula estipula que los datos permanecen en una zona geográfica definida. El cumplimiento se basa en la confianza en el respeto de este contrato por parte del proveedor.

Lexiane ofrece una alternativa diferente por naturaleza: en su configuración air-gapped, los datos no salen de su perímetro porque la arquitectura lo hace físicamente imposible — no porque un contrato lo prohíba. No hay llamada de red que vigilar ni flujo que auditar: el binario no dispone de ninguna interfaz de red activa hacia el exterior. Ningún documento, ningún fragmento, ningún embedding puede salir de su infraestructura.

Para un delegado de protección de datos, la diferencia es fundamental: se trata de una garantía arquitectural, no de una garantía contractual.

El filtrado PII: antes del dato, no después

El filtro de datos personales de Lexiane opera en origen del pipeline — antes de cualquier vectorización, cualquier indexación, cualquier llamada a un modelo de lenguaje. Las categorías detectadas cubren los datos personales más comunes en los corpus documentales profesionales: direcciones de correo electrónico, números de teléfono, IBAN, números de seguridad social, direcciones IP.

Están disponibles tres políticas de tratamiento configurables por categoría de dato:

• Enmascaramiento tipado — el valor se sustituye por un placeholder semántico ([EMAIL], [IBAN], [NSS]). El tipo del dato permanece legible para el tratamiento semántico. El valor es inaccesible.
• Supresión — el valor se retira del fragmento antes de cualquier transmisión al pipeline.
• Hash — el valor se sustituye por su huella criptográfica. La coherencia referencial se preserva sin exponer el dato en claro.

El cumplimiento RGPD no se trata como una etapa de postproducción. Está inscrito en el flujo de tratamiento como una restricción previa a cualquier operación sensible.

El audit trail como registro de tratamiento

El RGPD impone a los responsables del tratamiento llevar un registro de las actividades de tratamiento y poder demostrar la conformidad de sus tratamientos a petición de un regulador. El audit trail criptográfico de Lexiane constituye un registro técnico de cada operación realizada sobre cada documento: identidad del documento, marca de tiempo, operaciones aplicadas, políticas de filtrado activadas, accesos de usuarios.

Este registro no es un journal de logs. Es una cadena SHA-256: cada entrada está firmada por el hash de la anterior. Cualquier modificación retrospectiva de un registro es matemáticamente detectable. La prueba de conformidad está en la cadena misma — no en una declaración.

---

Regulaciones sectoriales: lo que Lexiane hace posible

Salud y dispositivos médicos — IEC 62304 Ed. 2

La revisión de la norma IEC 62304, cuya publicación está prevista para agosto de 2026, introducirá por primera vez exigencias explícitas sobre los softwares que incorporan componentes de inteligencia artificial y machine learning. Para los fabricantes de dispositivos médicos que desarrollan o integran hoy sistemas documentales basados en IA, este plazo no es lejano: un ciclo de certificación se cuenta en años, no en meses.

Lexiane es el único motor RAG concebido desde sus fundamentos para responder a este referencial:

• Perímetro certificado con #![forbid(unsafe_code)] — las propiedades de seguridad son verificables en tiempo de compilación
• Aislamiento explícito del SOUP por arquitectura hexagonal — las dependencias terceras están documentadas y delimitadas por interfaces tipadas
• Audit trail SHA-256 sobre cada decisión del pipeline — la trazabilidad es estructural, no opcional
• Compatibilidad con Ferrocene — el compilador Rust cualificado IEC 62304 e ISO 26262 (ver más abajo)
• Ausencia de comportamiento indefinido garantizada por el sistema de tipos — las categorías de bugs clasificadas como riesgos en IEC 62304 se eliminan por construcción

Para un fabricante de dispositivos médicos, esto significa que el expediente de cualificación del componente software IA puede basarse en pruebas mecánicas — no solo en procesos declarados.

Automoción y sistemas embebidos — ISO 26262

La integración de la IA en los sistemas embebidos de automoción plantea cuestiones de seguridad funcional que ISO 26262 no puede ignorar. Un sistema que procesa información sobre un vehículo — manuales técnicos, diagnósticos, bases de conocimiento de producto — debe satisfacer exigencias de determinismo y auditabilidad incompatibles con las características estructurales de los frameworks Python.

Lexiane responde a estas exigencias mediante dos propiedades fundamentales:

La ausencia de garbage collector. Rust gestiona la memoria estáticamente, sin mecanismo de recolección automática. No hay pausa GC imprevisible susceptible de violar una restricción de tiempo real. El comportamiento temporal del sistema es determinista por construcción — una propiedad que los runtimes Python o JVM no pueden ofrecer.

El binario estático autónomo. Lexiane se compila en un único binario sin dependencia dinámica. No requiere intérprete, ni máquina virtual, ni gestor de paquetes. En un entorno embebido sin conectividad de red permanente, esta propiedad es esencial: el sistema funciona tal como fue cualificado, sin dependencia de un entorno de ejecución externo susceptible de evolucionar.

Compilable con Ferrocene, Lexiane puede integrarse en un expediente de cualificación ASIL D — el nivel más exigente de la norma ISO 26262.

Finanzas — DORA y exigencias prudenciales

El reglamento DORA (Digital Operational Resilience Act), aplicable desde enero de 2025, impone a las entidades financieras exigencias reforzadas de resiliencia operacional digital, gestión de riesgos relacionados con terceros, y trazabilidad de los sistemas críticos.

Para una institución financiera que despliega un sistema IA sobre datos internos — informes de riesgo, documentación regulatoria, procedimientos operacionales —, Lexiane aporta garantías directamente pertinentes:

• Independencia respecto a terceros: cada componente de Lexiane es intercambiable a través de sus interfaces de abstracción. La dependencia a un único proveedor de LLM o de embeddings se elimina por arquitectura. Si un proveedor se vuelve no disponible o modifica sus condiciones, la migración no afecta al pipeline ni a los datos indexados.
• Trazabilidad de las decisiones: el audit trail SHA-256 documenta cada acceso a los datos, cada respuesta producida y sus fuentes. Para un supervisor o un auditor interno, cada decisión del sistema es reconstituible.
• Despliegue on-premise total: los datos financieros sensibles no transitan por infraestructuras terceras. La localización es controlable y documentable.

Sector público — RGPD, NIS2 y soberanía digital

Las administraciones públicas están sometidas a una doble restricción estructural: tratar volúmenes crecientes de documentación regulatoria y administrativa, garantizando al mismo tiempo que los datos de los ciudadanos y la información sensible permanezcan bajo control soberano.

NIS2, RGPD, y las orientaciones crecientes hacia soluciones cualificadas SecNumCloud hacen ineludible la cuestión de la residencia de los datos y de la auditabilidad de los sistemas IA. Lexiane ofrece aquí una respuesta arquitectural: el despliegue air-gapped excluye estructuralmente cualquier transferencia de datos hacia un proveedor tercero, independientemente de su localización o de sus compromisos contractuales.

---

Ferrocene: cuando el compilador mismo forma parte del expediente de cualificación

La cadena de confianza de un sistema certificado no se detiene en el código fuente. Incluye la herramienta que transforma ese código en binario ejecutable. Este es el desafío de la cualificación del compilador.

Ferrocene es la versión cualificada del compilador Rust, desarrollada por Ferrous Systems. Está cualificado ISO 26262 hasta el nivel ASIL D (sistemas de automoción) y IEC 61508 SIL 4 (seguridad funcional industrial). La cualificación IEC 62304 Ed. 2, que integrará exigencias explícitas sobre los sistemas IA/ML, se anticipa para acompañar la publicación de la norma en 2026.

Ferrocene proporciona a sus usuarios paquetes de evidencia — conjuntos documentales estructurados que permiten al auditor verificar que el propio compilador satisface las exigencias del referencial objetivo. La cadena de confianza es completa: del código fuente, al compilador, hasta el binario desplegado en producción.

Lexiane está concebido para ser compilado con Ferrocene. Para un fabricante de dispositivos médicos, un proveedor de automoción o un integrador de defensa, esto significa que no hay eslabón faltante en el expediente de cualificación.

Ningún framework RAG Python puede ofrecer tal garantía. No por falta de cuidado de sus desarrolladores — sino porque Python no dispone de un compilador cualificado equivalente, y el conjunto de sus dependencias de ejecución constituiría un volumen de SOUP que ningún referencial de certificación puede absorber razonablemente.

---

Lo que sus auditores obtienen concretamente

Un expediente de cualificación o una auditoría de conformidad sobre un sistema IA requiere pruebas — no declaraciones. Esto es lo que Lexiane pone a disposición:

Perímetro certificado delimitado y verificable El núcleo certificado es un módulo de compilación autónomo (vectrant-core), sin dependencias de proveedor, cuyas propiedades de seguridad son aplicadas por el compilador. Su frontera es la lista de sus 25 interfaces de abstracción. Es precisa, estable e inspeccionable.

Audit trail SHA-256 exportable Cada acción del pipeline está registrada en una cadena criptográfica cuya integridad es verificable matemáticamente. El registro es exportable y consultable independientemente del sistema en producción.

Suite de tests automatizada en integración continua 1 254 tests pasan de forma continua. Ningún test está desactivado por comodidad — los 39 tests ignorados lo están explícitamente porque requieren una infraestructura externa (instancia Qdrant, clave API, modelo descargado), y esta desactivación está documentada. La distinción entre tests unitarios, tests de integración y tests que requieren infraestructura es explícita en la estructura del proyecto.

Validación estática de la configuración en el ensamblado Los errores de configuración del pipeline se detectan en el ensamblado, antes de la ejecución. Un pipeline mal configurado no puede arrancar. Esta propiedad reduce la superficie de comportamientos indefinidos en producción.

Documentación del aislamiento SOUP Las 25 interfaces de abstracción constituyen la lista completa de los puntos de contacto entre el núcleo certificado y los componentes terceros. Cada interfaz está documentada, tipada y testeada. El conjunto de las dependencias externas son adaptadores que implementan estas interfaces — su estatus SOUP está delimitado por arquitectura.

---

Preguntas frecuentes de los responsables de cumplimiento

Nuestro referencial impone una cualificación del compilador. ¿Está reconocido Rust/Ferrocene? Ferrocene está cualificado ISO 26262 ASIL D e IEC 61508 SIL 4. La cualificación IEC 62304 está en proceso de elaboración para acompañar la revisión de la norma. Para otros referenciales, Ferrous Systems proporciona paquetes de evidencia que permiten iniciar el diálogo con su organismo de certificación.

Debemos documentar todos los componentes SOUP. ¿Cómo lo facilita Lexiane? La arquitectura hexagonal de Lexiane delimita el SOUP por construcción: todo componente externo implementa una interfaz de abstracción tipada. La lista de interfaces es la lista completa de las fronteras SOUP. Las dependencias transitivas de cada adaptador están aisladas en su propio módulo de compilación, sin acceso al núcleo certificado.

Nuestro auditor solicita inspeccionar el código del sistema. ¿Cómo accedemos a él? Lexiane se distribuye bajo licencia Apache 2.0 — el código fuente está íntegramente disponible e inspeccionable. No hay componente cerrado, no hay módulo binario opaco, no hay funcionalidad cuyo comportamiento no sea verificable en el código.

Debemos demostrar que los datos personales no salen de nuestro perímetro. ¿Cómo aportar la prueba? En configuración air-gapped, Lexiane no dispone de ninguna interfaz de red activa hacia el exterior. La prueba no es contractual — es arquitectural. Un auditor puede verificar, a la inspección del binario y de su configuración, que ninguna llamada de red saliente es posible. Es una propiedad diferente por naturaleza de un compromiso de confidencialidad de proveedor.

Contemplamos una certificación en 18 meses. ¿Por dónde empezar? La anticipación es precisamente lo que Lexiane permite. Su concepción para la certificación significa que las propiedades requeridas están presentes desde el despliegue — no tienen que añadirse retrospectivamente. Proponemos un intercambio sobre su referencial objetivo, su perímetro, y las etapas de su proceso de cualificación.

---

Iniciar la conversación sobre su contexto regulatorio.

Cada referencial de certificación plantea sus propias exigencias. Cada sector tiene su propia lectura del cumplimiento IA. No proponemos una respuesta genérica.

Proponemos un intercambio con alguien que conoce las restricciones de los entornos regulados, los desafíos de la certificación de software, y lo que la arquitectura de Lexiane permite concretamente en su contexto.

Lo que puede esperar de este intercambio:

• Una respuesta en 48h hábiles
• Un interlocutor técnico que conoce IEC 62304, ISO 26262, DORA y el RGPD en su relación con la IA
• Una evaluación honesta de la adecuación entre Lexiane y sus exigencias de certificación — incluyendo si son necesarios desarrollos complementarios

→ Contactar