Verificación formal: la única vía para satisfacer a los reguladores de IA
La conversación que nunca sale bien
Imagina esta escena. Ocurre cada semana en salas de juntas de toda Europa, en reuniones de revisión de la FDA, en oficinas de suscripción de seguros. Un ingeniero de IA presenta su último sistema a reguladores, abogados o evaluadores de riesgos.
«Nuestra bomba de insulina autónoma alcanzó una precisión del 99,97 % en 50 millones de escenarios de prueba», anuncia el ingeniero con orgullo, mientras pasa a una diapositiva llena de métricas impresionantes. «Lo último en tecnología. Mejor que cualquier endocrinólogo humano».
La sala queda en silencio. La reguladora se inclina hacia delante.
«Entonces me está diciendo», dice lentamente, «que de cada 10 000 dosis de insulina que administra este dispositivo... ¿tres podrían ser erróneas?»
El ingeniero se mueve incómodo en su asiento. «Bueno, estadísticamente hablando...»
«Solo en Alemania, aproximadamente 7 millones de personas tienen diabetes que requiere terapia con insulina. Si cada persona recibe solo cuatro dosis al día, eso son 28 millones de administraciones diarias. Con su tasa de error del 0,03 %...» Hace los cálculos en su bloc de notas. «Son 8400 posibles errores de dosificación. Cada día».
«Pero la mayoría de esos errores no serían clínicamente significativos...»
«¿Puede decirme cuáles lo serían?»
Silencio.
«¿Puede decirme cuándo ocurrirá el próximo fallo? ¿Puede decirme por qué fallará?»
Más silencio.
«Entonces me temo que no podemos aprobar este dispositivo».
Esta conversación, en sus distintas formas, se repite constantemente a medida que la IA pasa de los laboratorios de investigación al mundo físico. Y revela una brecha epistemológica fundamental entre cómo piensan los ingenieros de IA sobre la seguridad y cómo piensan sobre ella los reguladores, los abogados y los tribunales.
La barrera del idioma que no es cuestión de idioma
Cuando el ingeniero de IA dice «99,97 % de precisión», cree de verdad que está describiendo algo impresionante y seguro. En el mundo de los puntos de referencia del aprendizaje automático, esa cifra se celebraría. Se publicarían artículos. Los inversores se entusiasmarían.
Pero el regulador oye algo completamente distinto. Oye: «Existe una probabilidad pequeña pero no nula de que este sistema falle de forma catastrófica, y no tenemos ni idea de cuándo, dónde ni por qué ocurrirá».
Esto no es un problema de comunicación. No es que los ingenieros necesiten mejores dotes de presentación ni que los reguladores necesiten formación técnica. Es un choque fundamental entre dos conceptos distintos de lo que significa realmente «saber que algo funciona».
En el software de consumo, los enfoques probabilísticos son perfectamente aceptables. Si Netflix te recomienda una película que odias, no muere nadie. Si Spotify sugiere una canción que no encaja con tu gusto, lo peor que puede pasar es una leve molestia. Estos sistemas pueden permitirse fallar a veces porque el coste del fallo es trivial.
Pero la IA está avanzando rápidamente más allá de las recomendaciones de consumo hacia ámbitos donde el fallo tiene consecuencias físicas, legales y morales: vehículos autónomos que toman decisiones en fracciones de segundo sobre peatones, dispositivos médicos que calculan dosis de medicamentos, robots industriales que operan junto a trabajadores humanos, sistemas financieros que aprueban o deniegan créditos que determinan si las familias pueden comprar una vivienda.
En estos ámbitos, «bastante seguro de que funciona» no es suficiente. Los tribunales no aceptan distribuciones de probabilidad como prueba. Los actuarios de seguros no pueden fijar precios de pólizas para modos de fallo desconocidos. Los reguladores no pueden aprobar dispositivos que podrían matar a personas por razones que nadie puede explicar.
Por qué las pruebas, por muy exhaustivas que sean, no pueden garantizar la seguridad
El paradigma dominante en la evaluación de la IA hoy en día son las pruebas empíricas sobre conjuntos de datos reservados. Entrenas tu modelo con el conjunto de datos A y luego lo evalúas con el conjunto de datos B. Si funciona bien con B, asumes que ha «aprendido» la tarea subyacente y que generalizará al despliegue en el mundo real.
Este enfoque tiene tres problemas fundamentales que ninguna cantidad de pruebas puede resolver.
Problema uno: el espacio de entrada infinito
Las pruebas solo pueden demostrar la presencia de errores, nunca su ausencia. Por muchas pruebas que ejecutes, estás muestreando un espacio de entrada infinito. Un sistema que controla un dispositivo médico debe manejar no solo los escenarios de prueba que imaginaste, sino todas las combinaciones posibles de fisiologías de pacientes, condiciones ambientales, lecturas de sensores y casos límite que el mundo real acabará produciendo.
Imagina intentar demostrar que no hay agujas en un pajar recogiendo trozos de paja al azar. Tras examinar un millón de trozos y no encontrar ninguna aguja, no puedes concluir que el pajar está libre de agujas. Solo puedes decir que aún no has encontrado una. Las pruebas funcionan igual. Por muchos escenarios que superen, el siguiente podría fallar.
Problema dos: la vulnerabilidad adversaria
Las redes neuronales profundas son especialmente vulnerables a las entradas adversarias. Se trata de perturbaciones cuidadosamente diseñadas que hacen que los modelos fallen de forma catastrófica mientras parecen normales a los observadores humanos.
Un modelo podría clasificar correctamente las señales de stop el 99,99 % de las veces, pero una pequeña pegatina colocada en una ubicación concreta podría hacer que clasificara con total seguridad la señal como una señal de límite de velocidad. Un modelo podría identificar con precisión afecciones médicas en miles de radiografías, pero un patrón específico de ruido, invisible para los radiólogos humanos, podría hacer que pasara por alto tumores evidentes.
No son preocupaciones teóricas. Los investigadores han demostrado ataques adversarios contra todas las clases principales de arquitecturas de redes neuronales. Y los ataques son cada vez más fáciles de construir, mientras que las defensas siguen siendo incompletas.
Las pruebas no pueden proteger contra las vulnerabilidades adversarias porque la superficie de ataque es infinita. Habría que probar no solo las entradas normales, sino también todas las perturbaciones posibles de cada entrada normal. Eso es matemáticamente imposible.
Problema tres: el cambio distribucional
El mundo real no se queda quieto. La distribución de datos con la que se entrenó el modelo se desplazará con el tiempo. Las poblaciones de pacientes cambian. Las condiciones de conducción evolucionan. Los procesos de fabricación varían. Se produce degradación de los sensores.
Un modelo que funciona a la perfección con los datos de hoy puede fallar silenciosamente cuando los datos de mañana se desplacen fuera de su distribución de entrenamiento. Y, a diferencia de los errores explícitos que hacen fallar los programas, estos fallos suelen producir resultados seguros, plausibles, pero incorrectos.
Probar con los datos de hoy no te dice nada sobre el rendimiento de mañana. Cuando observas el fallo en producción, el daño ya se ha producido.
Verificación formal: las matemáticas como lenguaje universal de la seguridad
La verificación formal ofrece un enfoque completamente distinto. En lugar de preguntar "¿funcionó el sistema en estos casos de prueba?", pregunta "¿podemos demostrar matemáticamente que el sistema cumplirá una propiedad para todas las entradas posibles?"
La diferencia es profunda. Las pruebas muestrean el espacio de entradas. La verificación razona de forma exhaustiva sobre todo el espacio.
Consideremos un brazo robótico que trabaja junto a personas en una fábrica. Queremos garantizar una propiedad de seguridad: "El brazo nunca debe superar los 2 metros por segundo cuando se detecta a una persona a menos de 1 metro."
El enfoque de pruebas ejecuta el brazo en miles de escenarios con humanos simulados en distintas posiciones y velocidades, midiendo si se viola alguna vez el límite de seguridad. Si no se observan violaciones, se declara que el sistema es "seguro". Pero el siguiente escenario, el que no se probó, podría ser el que lesione a un trabajador.
El enfoque de verificación es fundamentalmente distinto. Tomamos el modelo matemático del sistema de control, incluida la red neuronal que procesa los datos de los sensores y el controlador que genera los comandos de los motores. Expresamos la propiedad de seguridad como una restricción formal. Luego usamos algoritmos especializados llamados solucionadores SMT (Satisfiability Modulo Theories) para responder una pregunta precisa: "¿Existe alguna configuración de entrada, dentro del rango operativo válido, para la cual la velocidad de salida supere los 2 m/s cuando se detecta proximidad humana?"
El solucionador no prueba puntos aleatorios. Analiza la estructura matemática de todo el sistema. Razona sobre la geometría del espacio de funciones. Si devuelve "UNSAT" (insatisfacible), tenemos una prueba matemática de que no existe ninguna entrada que viole la propiedad. La propiedad de seguridad se cumple no solo para los casos que probamos, sino para todos los casos posibles que puedan ocurrir.
Esta es la diferencia entre "revisé muchos puentes y ninguno se derrumbó" y "la física de estos materiales garantiza matemáticamente que este puente no puede derrumbarse bajo esta carga". Una es una observación empírica sujeta a revisión. La otra es una certeza lógica.
Por qué la IA moderna se resiste a la verificación
Si la verificación formal es tan potente, ¿por qué no la usa todo el mundo? ¿Por qué empresas como OpenAI y Google dependen del "red teaming" (personas que intentan romper el modelo) en lugar de pruebas matemáticas?
La respuesta está en las decisiones arquitectónicas que ha tomado la industria. Los grandes modelos de lenguaje modernos y las redes neuronales profundas están diseñados para la expresividad, no para la verificabilidad. Están optimizados para generar resultados creativos, no para ser matemáticamente analizables.
Un modelo transformer típico tiene miles de millones o billones de parámetros. Usa funciones de activación complejas y no lineales como GeLU o Swish. La complejidad matemática de verificar un sistema así escala exponencialmente con el número de neuronas y la profundidad de la red.
Demostrar una propiedad en un transformer de mil millones de parámetros es computacionalmente intratable. El universo alcanzaría la muerte térmica antes de que el solucionador terminara de explorar todas las ramas matemáticas. La industria ha construido sistemas tan complejos que ni siquiera sus creadores pueden analizarlos por completo.
Esto es una decisión de diseño, no una inevitabilidad. La industria se optimizó para demostraciones impresionantes y puntuaciones de referencia sin considerar si los sistemas resultantes podrían implementarse alguna vez de forma segura en entornos regulados.
La arquitectura Dweve: verificable por diseño
En Dweve tomamos decisiones arquitectónicas diferentes. Diseñamos nuestros sistemas desde cero para que fueran verificables, porque entendimos que los clientes empresariales e industriales necesitarían eventualmente satisfacer a los reguladores, no solo impresionarlos.
Nuestro enfoque combina dos innovaciones clave que hacen que la verificación sea manejable.
Descubrimiento de restricciones binarias: matemáticas simples
En lugar de redes neuronales masivas de coma flotante con miles de millones de parámetros continuos, los sistemas Dweve utilizan el Descubrimiento de restricciones binarias. El conocimiento se representa como restricciones lógicas discretas en lugar de pesos continuos aprendidos.
Nuestra biblioteca Dweve Core contiene 1.937 algoritmos optimizados para hardware basados en operaciones binarias: XNOR, AND, OR, POPCNT. Estas operaciones tienen propiedades matemáticas simples y bien comprendidas. Una restricción binaria se cumple o no se cumple. No hay incertidumbre probabilística.
Al restringir las matemáticas a relaciones lineales simples y lógica booleana, reducimos drásticamente el espacio de búsqueda de verificación. Los problemas que serían intratables para redes neuronales continuas se vuelven resolubles para nuestros sistemas de restricciones binarias. El problema de verificación se transforma de una optimización no lineal imposible a problemas resolubles de Programación Lineal Entera Mixta (MILP) o SAT.
Estos siguen siendo problemas computacionalmente difíciles, pero para el tamaño de los sistemas que implementamos en aplicaciones críticas para la seguridad, los solucionadores modernos pueden manejarlos en segundos o minutos en lugar de siglos.
La arquitectura de autonomía limitada de seis capas
No intentamos verificar todos los aspectos de la percepción de la IA. Reconocer que "una cuadrícula de píxeles representa a un humano" es inherentemente un juicio difuso y probabilístico. No se puede probar formalmente que el reconocimiento de patrones sea siempre correcto porque la corrección depende de definiciones subjetivas.
En su lugar, implementamos una arquitectura de seguridad en capas donde los componentes probabilísticos de la IA están limitados por restricciones lógicas verificadas formalmente. La IA puede sugerir acciones, pero esas sugerencias deben pasar por compuertas de seguridad verificadas antes de la ejecución.
Dweve Nexus implementa seis capas de aplicación de seguridad:
- Verificación de intenciones: Valida que las acciones de la IA se alineen con los objetivos declarados
- Autonomía limitada: Límites estrictos sobre qué acciones son permisibles independientemente de las sugerencias de la IA
- Moderación de contenido: Filtra las salidas por seguridad y adecuación
- Aplicación de ética: Garantiza el cumplimiento de las restricciones éticas definidas
- Detección de anomalías: Identifica cuándo el comportamiento de la IA se desvía de los patrones esperados
- Supervisión en tiempo de ejecución: Verificación continua de que se mantienen los invariantes de seguridad
La idea clave es que solo necesitamos verificar formalmente las capas de seguridad, no todo el sistema de IA. Incluso si la IA subyacente comete un error, la capa de autonomía limitada garantiza matemáticamente que los comandos peligrosos nunca lleguen a los actuadores.
Las matemáticas regulatorias: por qué la verificación crea valor empresarial
Para nuestros clientes, la verificación formal no es un ejercicio académico. Es una ventaja competitiva que se traduce directamente en resultados empresariales.
Aprobación regulatoria más rápida
Cuando un fabricante de dispositivos médicos acude a la FDA o a la EMA con un sistema basado en IA, los reguladores actúan con la cautela adecuada. Saben que la IA puede ser impredecible. Los procesos de aprobación estándar requieren años de ensayos clínicos para demostrar la seguridad de forma estadística.
Pero un fabricante que utiliza componentes Dweve verificados formalmente puede cambiar el rumbo de la conversación. En lugar de presentar resultados de pruebas que demuestran "aún no hemos observado fallos", pueden presentar demostraciones matemáticas que prueban que "los fallos son imposibles dentro de estos límites".
"No solo creemos que esta bomba de insulina no sobredosificará a los pacientes. Aquí está la demostración formal de que la dosis de salida está matemáticamente acotada por las restricciones de peso del paciente y nivel de glucosa. La violación no es simplemente improbable. Es lógicamente imposible."
Esto permite vías de revisión acelerada. Los reguladores pueden verificar la demostración de forma independiente. No necesitan confiar en el proceso de pruebas; pueden examinar las matemáticas directamente.
Primas de seguro reducidas
Los actuarios de seguros se enfrentan a un problema imposible con los sistemas de IA tradicionales. ¿Cómo se fija el precio del riesgo para modos de fallo que no se pueden predecir ni explicar? El resultado son primas extremadamente altas para cubrir riesgos desconocidos, o cláusulas de exclusión que hacen que el seguro sea prácticamente inútil.
Los sistemas verificados cambian el cálculo actuarial. Si una demostración matemática garantiza que ciertos tipos de fallos no pueden ocurrir, esos modos de fallo pueden excluirse del modelo de riesgo. Los riesgos restantes son cuantificables. Las primas disminuyen en consecuencia.
Algunos de nuestros clientes han visto cómo sus costes de seguro de responsabilidad civil se reducían entre un 40 y un 60 % tras implementar capas de seguridad verificadas, simplemente porque las aseguradoras ahora pueden calcular riesgos acotados en lugar de fijar precios para una incertidumbre ilimitada.
Defensa legal sólida
Cuando los sistemas de IA causan daños, llegan los litigios. En los despliegues tradicionales de IA, defender el sistema es casi imposible. "¿Cómo tomó su sistema esta decisión?" "No lo sabemos exactamente, es una red neuronal con miles de millones de parámetros..." Esta respuesta no satisface a ningún juez ni jurado.
Los sistemas verificados ofrecen una defensa diferente: "Aquí está la restricción de seguridad. Aquí está la demostración matemática de que la restricción no puede violarse. El daño ocurrió fuera del límite verificado, lo que indica factores externos, no un fallo del sistema."
No se trata de evitar la responsabilidad. Se trata de poder demostrar exactamente qué garantías se hicieron y si se cumplieron. Los tribunales entienden la lógica formal. Entienden las demostraciones matemáticas. No entienden los intervalos de confianza probabilísticos.
La Ley de IA de la UE: la verificación se vuelve obligatoria
Las ventajas teóricas de la verificación formal se están convirtiendo en requisitos prácticos. La Ley de IA de la UE, que entró en vigor en 2024 con una implementación gradual hasta 2027, cambia fundamentalmente lo que se exige legalmente para los despliegues de IA en Europa.
Para los sistemas de IA de "alto riesgo", que incluyen dispositivos médicos, decisiones de empleo, evaluaciones de solvencia crediticia y muchas aplicaciones industriales, la Ley exige:
- Sistemas de gestión de riesgos que identifiquen y mitiguen riesgos previsibles
- Datos de entrenamiento de alta calidad con procedencia documentada
- Capacidades de registro que permitan el seguimiento del comportamiento del sistema
- Transparencia para los usuarios sobre las decisiones tomadas por la IA
- Mecanismos de supervisión humana que permitan la intervención
- Precisión, robustez y ciberseguridad adecuadas a la aplicación
Observe el lenguaje: "riesgos previsibles", "comportamiento trazable", "precisión adecuada a la aplicación". No son aspiraciones vagas. Son requisitos legales con capacidad de ejecución, incluidas multas de hasta 35 millones de euros o el 7 % de la facturación global.
¿Cómo demuestra que ha identificado y mitigado "riesgos previsibles" en una red neuronal con miles de millones de parámetros cuyo proceso de decisión es opaco incluso para sus creadores? ¿Cómo demuestra que el comportamiento es "trazable" cuando el sistema produce resultados mediante multiplicaciones de matrices incomprensibles?
Las arquitecturas de IA tradicionales no pueden satisfacer estos requisitos solo con documentación y pruebas. Pero los sistemas verificados sí pueden. La prueba es la documentación. La garantía matemática es la mitigación. Las restricciones lógicas son la trazabilidad.
Los 456 especialistas de dominio: escala verificable
Una objeción habitual a la IA verificada es que la verificación no escala. Para sistemas simples con unas pocas reglas, sí, la verificación funciona. Pero la IA del mundo real necesita gestionar percepción y razonamiento complejos. ¿Cómo puede funcionar la verificación a escala?
Dweve Loom demuestra que la verificación y la capacidad no son mutuamente excluyentes. Nuestro modelo fundacional utiliza 456 conjuntos de restricciones especializados, cada uno con 64-128 MB de restricciones binarias. Pero solo se activan de 4 a 8 especialistas de dominio para cualquier consulta determinada.
Esta arquitectura, que denominamos activación ultra dispersa, implica que el esfuerzo de verificación escala con el subconjunto activo, no con el modelo completo. No necesitamos verificar las 456 combinaciones de especialistas de dominio simultáneamente. Verificamos la lógica de enrutamiento que selecciona los especialistas de dominio, y verificamos el conjunto de restricciones de cada especialista de dominio de forma independiente.
El sistema de enrutamiento Permuted Agreement Popcount (PAP) utiliza la detección de patrones estructurales para seleccionar los especialistas de dominio relevantes. Esta capa de enrutamiento es en sí misma formalmente verificable porque opera con operaciones binarias discretas con propiedades matemáticas bien definidas.
El resultado es un sistema que puede manejar tareas complejas del mundo real manteniendo la trazabilidad de la verificación. Obtenemos los beneficios de capacidad de las arquitecturas de mezcla de expertos con los beneficios de seguridad de la verificación formal.
Implementación: cómo es realmente la verificación
Para las organizaciones que consideran el despliegue de IA verificada, el proceso práctico implica varias etapas.
Etapa 1: especificación de propiedades
Antes de que comience la verificación, debe definir qué propiedades necesitan verificarse. Este suele ser el paso más difícil, ya que requiere una estrecha colaboración entre expertos de dominio, ingenieros y equipos legales y de cumplimiento.
Las propiedades deben ser precisas y expresables matemáticamente. "El sistema debería ser seguro" no es una propiedad verificable. "El comando de velocidad del motor no debe superar V_max cuando el sensor de proximidad indica una distancia inferior a D_min" es verificable.
En Dweve, ayudamos a los clientes en este proceso de especificación mediante Spindle, nuestra plataforma empresarial de gobernanza del conocimiento. La jerarquía de 32 agentes incluye especialistas en cumplimiento normativo que ayudan a traducir los requisitos legales en restricciones formales.
Etapa 2: Mapeo de la arquitectura
La arquitectura del sistema de IA debe mapearse en un modelo formal que las herramientas de verificación puedan analizar. Para los sistemas Dweve, este mapeo es sencillo porque nuestra arquitectura de restricciones binarias fue diseñada para ser verificable.
Para organizaciones con despliegues existentes de redes neuronales, esta etapa puede requerir modificaciones arquitectónicas. Añadir capas de autonomía acotada alrededor de los modelos existentes, implementar restricciones de seguridad como envoltorios verificados o, en algunos casos, sustituir componentes no verificables por equivalentes de Dweve.
Etapa 3: Ejecución de la verificación
Los solvers SMT modernos y las herramientas de verificación formal analizan el modelo del sistema para demostrar las propiedades especificadas o identificar contraejemplos. Los contraejemplos son muy valiosos porque revelan exactamente qué entradas podrían vulnerar las restricciones de seguridad, lo que permite aplicar correcciones específicas.
Para los sistemas Dweve, la verificación suele completarse en minutos u horas, según la complejidad de las restricciones. Los 1.937 algoritmos de Dweve Core ya han sido preverificados para propiedades de seguridad comunes, por lo que la verificación suele consistir en componer componentes preverificados en lugar de empezar desde cero.
Etapa 4: Certificación y documentación
Las propiedades verificadas generan artefactos de prueba que sirven como evidencia de certificación. Estas pruebas son comprobables por máquina, lo que significa que los reguladores pueden verificarlas de forma independiente con herramientas estándar de comprobación de pruebas, sin necesidad de confiar en el proceso de verificación original.
Dweve Fabric, nuestro panel de control unificado de la plataforma, genera documentación de cumplimiento automáticamente a partir de los resultados de verificación. Las mismas pruebas que satisfacen al solver se convierten en el paquete de evidencia para la presentación regulatoria.
El futuro: la IA verificada como práctica estándar
Estamos en un punto de inflexión en el despliegue de la IA. La era de "muévete rápido y rompe cosas" está terminando para las aplicaciones de alto riesgo. El entorno regulatorio se está endureciendo. La exposición a responsabilidades está aumentando. Los desafíos de los seguros se están acumulando.
Las organizaciones que despliegan IA en industrias reguladas se enfrentan a una elección. Pueden continuar con arquitecturas tradicionales y enfrentarse a una fricción creciente: procesos de aprobación más largos, mayores costos de seguro, mayor exposición legal y posible exclusión del mercado a medida que las regulaciones entren en vigor.
O pueden adoptar arquitecturas verificadas que satisfagan a los reguladores con certeza matemática en lugar de esperanza estadística.
La revolución de la verificación no consiste en hacer que la IA sea menos capaz. Se trata de hacer que la IA sea confiable de maneras que importen a todos más allá del laboratorio de investigación: pacientes, operadores, aseguradoras, reguladores y tribunales. Se trata de construir IA que los humanos puedan desplegar realmente con confianza.
En Dweve, creemos que el futuro pertenece a los sistemas de IA que pueden demostrar su seguridad, no solo prometerla. Nuestra arquitectura, desde los 1.937 algoritmos verificados en Core hasta la autonomía acotada de seis capas en Nexus y los 456 conjuntos de restricciones especializadas por dominio en Loom, está construida desde cero para este futuro.
La matemática de la certeza no es una limitación para el progreso de la IA. Es la base para el despliegue de la IA a gran escala.
¿Listo para desplegar una IA que los reguladores puedan aprobar? La arquitectura formalmente verificada de Dweve ofrece las garantías matemáticas que convierten los obstáculos regulatorios en ventajas competitivas. Contacta con nosotros para hablar de cómo la verificación puede acelerar tu camino hacia el mercado mientras reduces tu exposición a responsabilidades.