Últimamente he estado leyendo algunas opiniones interesantes sobre por qué la mayoría de las organizaciones están básicamente volando a ciegas con sus sistemas de IA. ¿El problema principal? Estamos desplegando herramientas que fundamentalmente no podemos controlar ni arreglar cuando fallan.

Neel Somani, quien ha realizado trabajos de investigación serios en ciencias de la computación abarcando privacidad e IA, hace un punto que atraviesa mucho del ruido en torno al riesgo de la IA. Todos hablan del escenario Skynet, ¿verdad? La temática apocalíptica. Pero ese no es realmente el problema que enfrentan la mayoría de las empresas. La verdadera pesadilla operativa es más simple y desordenada: estás ejecutando sistemas que no puedes depurar, no puedes modificar con confianza, y definitivamente no puedes verificar.

Piensa en cómo funciona realmente la IA en la mayoría de las empresas en este momento. Un modelo marca una transacción como fraude. Recomienda a alguien para una contratación. Ajusta precios de manera dinámica. Luego te da una explicación después. Suena razonable. Pero aquí está lo importante: esa explicación está invertida para sonar plausible. No necesariamente refleja cómo el sistema realmente llegó a esa decisión. Cambia una variable de entrada y toda la lógica se desploma. La narrativa no coincide con el mecanismo.

Esa brecha crea dos riesgos operativos graves. Primero, fallos ocultos. Cuando la lógica interna es opaca, los problemas pueden propagarse de maneras que ninguna cantidad de pruebas detecta de antemano. Una solución para un problema silencia y rompe otra cosa, generalmente en condiciones específicas que nunca anticipaste. Segundo, fragilidad en la intervención. Incluso cuando identificas un problema, arreglarlo se vuelve peligroso. Ajusta un componente y otras partes del sistema se compensan de maneras que crean nuevos modos de fallo. Es como jugar a golpear la cabeza con un martillo en tu propia infraestructura.

El marco de Neel Somani aquí se centra en algo que llama depurabilidad. No interpretabilidad, eso es diferente. La depurabilidad significa tres capacidades específicas: ¿Puedes localizar qué mecanismos causaron una falla? ¿Puedes modificar esos mecanismos con precisión sin causar daños en cascada? ¿Puedes demostrar que la solución realmente funcionó?

La localización trata de identificar no solo qué capa de un modelo produjo una salida, sino si el comportamiento podría ocurrir sin ese mecanismo, o si el mecanismo podría estar activo sin producir ese comportamiento. La intervención implica modificar las partes responsables de manera predecible y dirigida, eliminando el comportamiento no deseado en tu dominio especificado sin romper cosas en otros lugares. La certificación significa hacer afirmaciones exhaustivas y falsables sobre el comportamiento del modelo en dominios limitados — no garantías probabilísticas, sino afirmaciones universales reales. Si falla dentro de ese dominio, tu certificación fue incorrecta.

Para los líderes, las implicaciones son bastante claras. La gestión de riesgos tradicional se basa en la transparencia y la auditabilidad. Rastrear decisiones hasta personas responsables. ¿Sistemas de IA caja negra? Todo ese marco se desmorona. Los organismos regulatorios están empezando a notarlo. La Ley de IA de la UE, los estándares de NIST, todos empujan hacia la explicabilidad y la supervisión. Pero aquí está el truco: puedes pasar una auditoría y aún así carecer de la capacidad técnica real para arreglar tus sistemas cuando fallan en producción.

La teatralidad de cumplimiento no equivale a capacidad operativa. La depurabilidad cambia la pregunta de "¿Estamos documentados?" a "¿Podemos arreglar esto realmente?" Cuando un sistema de IA se comporta mal, ¿tu organización puede identificar la causa raíz, modificar con confianza y verificar que la modificación funcionó? Sin esas capacidades, la gobernanza es solo apagar incendios reactivo. Mandas revisiones, requieres documentación, impones supervisión, pero nada de eso previene la falla subyacente.

Somani hace un paralelo interesante con el software crítico para la seguridad. No puedes probar que un navegador web nunca se bloquee. Pero puedes demostrar que rutinas específicas son seguras en memoria, que el sandboxing previene ciertos exploits, que las invariantes críticas sobreviven a actualizaciones, que los parches eliminan vulnerabilidades sin introducir regresiones. La misma lógica se aplica a la IA. El control significativo no se trata de garantías globales. Es de garantías composicionales, limitadas a dominios específicos. Asegurar que un subcircuito no pueda activar una función prohibida en entradas determinadas. Demostrar que una intervención elimina un modo de fallo mientras preserva otros comportamientos en alcance. Eso es lo que importa para despliegues de alto riesgo — finanzas, salud, cadenas de suministro, moderación de contenido.

El camino a seguir requiere inversión que la mayoría de las organizaciones no ha priorizado. La verificación formal, por ejemplo. Pruebas matemáticas que establecen propiedades del software. Tradicionalmente aplicadas a controladores de aviones y protocolos criptográficos, extender esto a la IA es técnicamente desafiante pero no imposible. Los avances recientes en extracción de circuitos dispersos muestran que modelos grandes contienen subcircuitos aislados estables bajo intervención. Los marcos de verificación neuronal demuestran que el razonamiento exhaustivo funciona cuando los modelos se descomponen en componentes aptos para verificación en dominios limitados.

Para los líderes, la decisión es si esperar a que estos métodos maduren o construir capacidad ahora. La espera conlleva riesgo. La implementación de IA se acelera. La brecha entre lo que las organizaciones despliegan y lo que controlan sigue ampliándose. La alternativa es invertir en equipos que entiendan tanto de IA como de métodos formales, establecer estándares internos para cuándo se requiere depurabilidad, asociarse con proveedores que prioricen sistemas verificables sobre la conveniencia de caja negra. Significa cambiar decisiones de adquisición. Al evaluar herramientas de IA, añade una cuarta pregunta más allá de precisión, velocidad y costo: ¿Podemos arreglar esto si se rompe?

La mayoría de las discusiones sobre riesgo de IA se centran en amenazas externas — ataques adversariales, envenenamiento de datos, actores maliciosos. Son preocupaciones legítimas, claro, pero distraen de la cuestión fundamental. Para la mayoría de las organizaciones, el riesgo principal no es IA armada. Es el fallo operativo ordinario y la falta de herramientas para responder. Eso es un problema de gobernanza, no de tecnología.

El argumento central de Neel Somani: el fin del manejo del riesgo de IA no es una mejor supervisión o más control. Es construir sistemas que sean depurables con la rigurosidad que exige la seguridad crítica en software hoy en día. Hasta que eso sea una práctica estándar, las organizaciones están desplegando sistemas que no controlan realmente. Para cualquier ejecutivo, la pregunta no es si la IA transformará tu industria — ya lo ha hecho. La pregunta es si tu organización realmente lo gobernará cuando importe.