Hay una frase que casi nunca aparece en los informes sobre inteligencia artificial en la empresa: que el momento en que muere un proyecto «rara vez es técnico». Sebastian Brickel la dice sin rodeos: «Es política interna». Los proyectos con un padrino fuerte siguen vivos mucho después de que su piloto haya dejado de tener sentido, y los que nacen sin apoyo los acaba cortando alguien desde arriba. Casi nunca falla el modelo.
Brickel es AI Governance Advisor en The Remote Consultant. Llegó a la gobernanza de la IA desde la química computacional, con un doctorado dedicado a simular cómo se comportan las moléculas, y eso se nota en cómo habla: poco lenguaje de negocios y mucha pregunta incómoda sobre lo que de verdad funciona. Su mirada se aparta de la del consultor habitual: para él una auditoría de IA no examina un sistema, examina los hábitos de una organización, empezando por la inteligencia artificial que entra en la empresa sin haber sido invitada y por la que viene escondida dentro de programas que ya se pagaban para otra cosa.
Habla además del Reglamento europeo de IA con una franqueza poco habitual: según él, la norma solo produce mejores sistemas donde la empresa ya iba a hacer el trabajo bien; en el resto produce sistemas de apariencia conforme, con los mismos problemas de fondo, pero ya documentados. Responde por escrito en El Domingo de Iberia, la sección de entrevistas de LaPrensaIA, en inglés, y estas son sus respuestas traducidas.
La entrevista
Dices que la mayoría de las iniciativas de IA fracasan antes de que nadie vea un resultado, no porque la tecnología sea errónea, sino porque nunca se construyó la gobernanza ni la alineación de la organización. ¿Dónde muere exactamente un proyecto? Pon nombre al momento.
La mayoría de las iniciativas de IA fracasan por falta de respaldo interno, no por la tecnología. Los proyectos internos sin socio externo rara vez mueren en un momento concreto: los recursos se agotan y se van apagando. Los proyectos externos con un fuerte patrocinio interno siguen el camino contrario: el razonamiento del coste hundido los mantiene vivos más allá del alcance original del piloto. Nadie los da por terminados. Los únicos proyectos que mueren a la vista de todos son los que desde el principio tenían un apoyo interno débil: tarde o temprano alguien de arriba los corta. El momento rara vez es técnico. Es política interna.
En un sector regulado, ¿qué tiene que demostrar un sistema de IA que nadie le pide en uno no regulado?
El sistema de IA en sí no necesita ser conforme; lo que tiene que serlo es el pipeline (la cadena de datos) que lo alimenta. Un modelo local propio, plenamente conforme, es la respuesta más limpia, pero pocas empresas lo construyen: el esfuerzo de ingeniería es considerable. La alternativa práctica es gobernar el pipeline: alimentar el modelo con datos anonimizados y tratados correctamente. El nivel de conformidad del modelo importa mucho menos. Una salvedad: en los sistemas de alto riesgo bajo la normativa, el propio sistema también tiene obligaciones —evaluación de conformidad, documentación, supervisión humana—, no solo los datos que lo alimentan. En un entorno regulado, el uso se sigue dividiendo en categorías reguladas y no reguladas. Un borrador de marketing interno tiene poco en juego; los datos de pacientes son una categoría completamente distinta. Si el pipeline está mal, ninguna calidad de modelo te salva.
¿Qué busca realmente una auditoría de gobernanza de IA? Cuéntame qué abres primero y qué sospechas ya al abrirlo.
En una empresa siempre hay más cosas en marcha de las que se han aprobado oficialmente. El primer paso es mapear todos los usos de IA de la organización y dividirlos de nuevo en regulados y no regulados. Después, buscar quién es responsable. La IA es una máquina de razonar, no un agente moral: no puede tener en exclusiva la autoridad para decidir. Cada sistema necesita una persona con nombre y apellidos que responda por él. No un comité. No un analista júnior que firma por inercia. En la práctica, poco de lo que se usa a diario ha pasado una revisión formal. Se extiende como siempre se ha extendido la shadow IT: un equipo adopta una herramienta porque es útil, sin autorización. El mapeo suele pasar por alto una cosa: la IA integrada en herramientas SaaS que ya se usan, contratadas para otra finalidad, que hacen trabajo de IA en silencio sin que nadie lo haya señalado. Eso es lo que hace tan difícil regular después. No estás auditando un sistema. Estás auditando los hábitos de una organización.
Asesoras a equipos directivos. ¿Cuál es la pregunta que hace un directivo sobre IA y que te dice enseguida que el proyecto va a tener problemas?
La señal de alarma más clara son los directivos que esperan demasiado, demasiado rápido y por muy poco dinero. Cuanto más entusiasmada está una persona con la tecnología, más problemas suele tener el proyecto. La IA es una herramienta, de la misma categoría que la automatización. En muchos flujos de trabajo, la automatización determinista basada en reglas ya es la respuesta correcta. «Ponme IA en todo» es el mayor predictor de que un proyecto se tuerza. La secuencia correcta: mirar el flujo de trabajo, optimizarlo, automatizar lo que se pueda automatizar y solo entonces incorporar IA donde aporte algo que la automatización no puede.
El Reglamento europeo de IA (EU AI Act) es la razón por la que muchas empresas se mueven. En tu experiencia, ¿produce mejores sistemas o mejor papeleo?
La mayoría de las normativas se anuncian con mucha antelación. La mayoría de las empresas esperan a que se acerque el plazo para actuar. Eso genera mucho papeleo de última hora, a menudo puro teatro, escrito para satisfacer a un auditor y no para cambiar cómo se construye o se supervisa un sistema. Tomados en serio, esos mismos requisitos de documentación obligan a algo útil: alguien tiene que nombrar la clasificación de riesgo, los flujos de datos y la persona responsable antes de que el sistema salga. La mayoría de las empresas se salta ese trabajo incluso sin regulación. Un análisis de appliedAI de 2023 sobre más de cien sistemas de IA empresariales concluyó que 40 no podían clasificarse con claridad en los niveles de riesgo, lo que dice algo sobre lo preparadas que están realmente la mayoría de las organizaciones. La norma no produce mejores sistemas por decreto. Solo los produce donde la empresa ya iba a hacer el trabajo bien y usa el plazo como palanca. Todos los demás acaban con un sistema de apariencia conforme que arrastra los mismos problemas de fondo, ahora documentados.
Las empresas rara vez admiten que un proyecto de IA ha fracasado: se rebautiza discretamente como piloto. ¿Qué tenía en común el fracaso más caro que has visto de cerca con los baratos?
Llamar «piloto» a un proyecto fallido es la forma más fácil de evitar admitir que no funcionó. Rara vez es un fallo de tecnología. Es un fallo de gestión del cambio. Y vale igual si el proyecto costó poco o mucho. Se puede contratar a un consultor, pero la adopción hay que vivirla dentro de la empresa. La IA no es especial en esto: fracasa igual que fracasa un CRM o un ERP nuevo cuando nadie lo usa de verdad. Los fracasos caros y los baratos se ven idénticos desde dentro: una herramienta que nadie fue obligado a adoptar, sin uso, rebautizada en silencio como prueba de concepto en lugar de reconocida como un error. En ambos casos, el análisis posterior dice «probamos la IA», nunca «no logramos que la gente la usara».
Llegaste a la estrategia de IA desde la química computacional, un doctorado en simular cómo se comportan las moléculas. ¿Qué te permite ver ese bagaje en un proyecto corporativo de IA que se le escapa a un consultor de negocio puro?
Una formación científica a nivel de doctorado significa depender menos del lenguaje de negocios y ser más directo sobre lo que realmente funciona. También da una base técnica sobre cómo llegó la IA a su estado actual, construida trabajando con aprendizaje automático antes de que fuera una palabra de moda. Estudiar el mundo natural enseña además otra lección: algunas reglas se cumplen con independencia de la moda o de la política interna. Seguir lo que funciona, en lugar de lo que está de moda o bien conectado, ofrece un punto de vista distinto del que se construye únicamente en la carrera corporativa.
El Dr. Sebastian Brickel es AI Governance Advisor en The Remote Consultant. Es doctor en simulación molecular y llegó a la gobernanza de la inteligencia artificial desde la química computacional, trabajando con aprendizaje automático antes de que fuera una palabra de moda. Perfil: LinkedIn. Responde por escrito a LaPrensaIA en inglés; la traducción al español es de la redacción, que se hace responsable de ella, y él la ha podido revisar antes de publicar. Sus respuestas se publican íntegras y en su orden original, con edición ortotipográfica mínima. Foto: Carol Caron, Semilla Fotografía.
Contenido elaborado con la asistencia tecnológica de IBERIA y supervisión editorial. Fermín Sánchez es el responsable editorial de LaPrensaIA, diario de divulgación sobre inteligencia artificial. Cubrimos la actualidad de la IA con criterio propio —tecnología, empresas y sociedad— de forma clara para el público no técnico.
