Gobernanza de la IA en una pyme: los controles que hacen defendible un caso de uso

Hay una pregunta que viene antes de elegir la herramienta y otra que viene después. La primera — «¿debo adaptarme al AI Act? ¿estoy obligado?» — la abordamos en el artículo sobre el EU AI Act para las pymes, y para la mayoría de las empresas la respuesta es más tranquila de lo previsto. Esta es la otra: una vez que ha decidido poner en producción un caso de uso — un copiloto para ventas, un bot de soporte, una automatización en administración — ¿cómo lo gobierna para que aguante? Que aguante un control de la autoridad italiana de protección de datos (Garante Privacy), una petición de un cliente, un incidente, la pregunta incómoda de un auditor.

Es una pregunta distinta de la conformidad formal, y es en la que vemos más ligereza. No «¿estoy en regla con la ley?», sino «si algo sale mal, ¿qué puedo mostrar?». La diferencia entre ambas es toda la gobernanza. Intentemos ponerla en orden, en lenguaje llano, sin alarmismos y sin convertirla en el típico documento de veinte páginas que nadie lee.

La gobernanza no es un documento: es un bloque que acompaña a cada caso de uso

El error más común es pensar en la gobernanza de la IA como en una política general — un PDF que declara principios y acaba en una carpeta. No funciona así, porque el riesgo no vive en la empresa en abstracto: vive en el workflow concreto. Un copiloto que sugiere respuestas en soporte y un sistema que filtra los CV entrantes tienen el mismo «nivel de atención empresarial», pero un perfil de riesgo incomparable. La gobernanza seria se engancha al caso de uso, no a la organización.

Lo que usamos — y es la estructura que recomendamos a cualquier pyme, incluso sin nosotros — es un bloque breve y repetible que acompaña a cada diseño de workflow. Cinco líneas, siempre las mismas:

• Nivel de riesgo — dónde recae el caso de uso en la escala del AI Act (casi siempre mínimo o limitado; alto solo para personal, crédito, biometría).
• ¿Hace falta una EIPD? — el control RGPD sobre el tratamiento de los datos personales implicados (véase más abajo: cuándo se activa y por qué la «estándar» no basta).
• Etiquetas de riesgo — una clasificación de las formas en que ese workflow puede fallar, con un vocabulario compartido en lugar de con palabras sueltas (véase la taxonomía del MIT más adelante).
• Mitigaciones — qué ponemos alrededor del riesgo: umbrales, límites de autonomía, revisión humana, minimización de datos.
• Vigilancia y trazabilidad — quién vigila la operativa y qué queda registrado, durante cuánto tiempo.

El valor de este bloque no es formal: es operativo. Cuando el Garante Privacy, un cliente o un auditor pregunta «¿cómo gestionan este sistema?», no responde con una filosofía — abre el bloque del workflow concreto y muestra las cinco líneas. Es la diferencia entre declararse gobernado y serlo de verdad.

La EIPD para la IA: cuándo hace falta, y por qué la «estándar» no basta

La evaluación de impacto relativa a la protección de datos (EIPD, art. 35 RGPD) es la primera herramienta concreta de la gobernanza, pero también la más malentendida. No hace falta siempre: se vuelve obligatoria cuando el tratamiento es «probablemente de alto riesgo». Hay tres casos que la hacen automática — decisiones automatizadas con efectos jurídicos o significativos sobre la persona, tratamiento a gran escala de datos especiales (salud, opiniones, biometría), y seguimiento sistemático de zonas accesibles al público — a los que el CEPD añade nueve criterios adicionales (elaboración de perfiles, evaluación, uso de tecnologías innovadoras). La mayoría de los despliegues de IA empresariales toca al menos uno.

Hasta aquí es RGPD clásico. El punto que casi ningún modelo tiene en cuenta es que una EIPD genérica, pensada para una base de datos o un software de gestión, pasa por alto los riesgos propios de la IA. Un modelo no es una tabla: tiene comportamientos que una evaluación tradicional no prevé. En una EIPD para la IA hay que añadir, como sección dedicada, al menos cuatro apartados que en otros sitios no existen:

• Opacidad del modelo — la decisión puede no ser explicable línea por línea. Si el workflow incide sobre una persona, «no sé por qué ha decidido así» es un problema de conformidad, no solo técnico.
• Deriva (drift) — un modelo que funcionaba bien se degrada con el tiempo si los datos de entrada cambian. Un control hecho una sola vez en el lanzamiento no basta: hay que repetirlo.
• Memorización de los datos de entrenamiento — un modelo puede regurgitar fragmentos de los datos con los que fue entrenado, incluida información personal. Es un vector de brecha que una base de datos no tiene.
• Conflicto con el derecho al olvido — borrar un dato personal de una base de datos es trivial; «desaprender» un dato de un modelo ya entrenado a menudo no lo es. La EIPD debe decir qué se hace cuando llega esa solicitud.

Si su consultor le propone la EIPD que usaría para cualquier software, sin esta sección, le está dando un formulario, no una evaluación. Y si la EIPD detecta un riesgo alto que no logra mitigar, el RGPD (art. 36) exige consultar a la autoridad de control antes de proceder: raro para una pyme, pero hay que preverlo como rama de escalado, no descubrirlo cuando el incidente ya ha ocurrido.

Un vocabulario compartido para el riesgo, en lugar de las palabras

«Este sistema es arriesgado» no es una información útil: es una impresión. El salto de calidad en la gobernanza es pasar de una prosa vaga a una etiqueta repetible y citable, la misma para todos los workflows, de modo que dos casos de uso distintos se puedan comparar. Por eso usamos como vocabulario de referencia el AI Risk Repository del MIT, que clasifica el riesgo en dos ejes:

• Cómo surge el riesgo (eje causal): la entidad que lo genera (humano / IA / otro), la intención (intencionada / no intencionada), el momento (antes o después del despliegue).
• Qué tipo de riesgo es (eje de dominio): siete dominios — discriminación, privacidad y seguridad, desinformación, uso doloso, interacción persona-máquina, efectos socioeconómicos, fallos y límites del sistema.

Un ejemplo hace concreto el método. Un copiloto para ventas que de vez en cuando «inventa» un detalle sobre un producto — la clásica alucinación — se etiqueta como (entidad: IA · intención: no intencionada · momento: después del despliegue) × (dominio: desinformación). No es un capricho académico: esa etiqueta le dice dónde actuar (aguas abajo, con una verificación humana sobre la salida antes de que llegue al cliente) y le da una palabra común para hablar de ello con quien no entiende el modelo. La prosa no lo hace: la etiqueta sí.

Los dos controles operativos que cuentan más que todos los demás

Se puede escribir una gobernanza elaborada y seguir expuesto; o mantener una ligera con dos controles sólidos y ser de verdad defendible. En casi todos los casos de uso de una pyme, estos dos marcan la diferencia.

El primero es el humano en el proceso. No como eslogan, sino como arquitectura: quién vigila la operativa del sistema, con qué autoridad para detenerlo, y sobre qué decisiones es obligatorio su paso. Es el mismo principio que hace defendible un agente en administración y finanzas — donde el resultado es irreversible porque mueve dinero — pero vale allí donde una decisión afecta a una persona. La regla práctica que damos: conceda autonomía al sistema solo allí donde el resultado sea reversible y verificable; todo lo demás pasa por una persona.

El segundo es la trazabilidad. Para los usos de alto riesgo el artículo 26 del AI Act pide al deployer conservar los logs durante al menos seis meses y notificar los incidentes graves; pero también fuera de ese perímetro, dejar constancia de qué ha decidido el sistema, sobre qué datos y quién ha aprobado es lo que transforma «nos fiamos» en «podemos demostrarlo». Un registro a prueba de auditoría, no un prompt. Es el control más económico de poner y el más caro de no tener cuando hace falta.

El marco italiano: la conformidad es un área viva, no una casilla

Quien le vende una gobernanza «de una vez y para siempre» no mira lo que ocurre en Italia. La Ley 132/2025 ha introducido los principios generales italianos sobre la IA y amplía el ámbito de la EIPD para los usos de inteligencia artificial más allá de la base del RGPD — lo que significa que hay que verificar los requisitos actuales antes de citarlos a un cliente, porque el texto es reciente y la materia se mueve. En el frente de los controles, el Garante para la protección de los datos personales ha programado, mediante su resolución de 30 de diciembre de 2025, al menos 40 actuaciones de inspección para el periodo enero-julio de 2026, y entre las áreas anunciadas figuran expresamente las comprobaciones sobre las herramientas de IA utilizadas en el ámbito escolar. Aunque su caso de uso esté lejos del aula, dice algo que cuenta: la actividad inspectora sobre la IA ya está programada, no es una hipótesis. La página del Garante sobre la IA es la fuente canónica que hay que revisar en cada proyecto, porque las orientaciones se actualizan a menudo.

La lectura práctica: la gobernanza no es un documento que se firma y se archiva, es una práctica que se revisa. Un modelo deriva, una norma cambia, un caso de uso se amplía — y el bloque de las cinco líneas hay que volver a abrirlo. Quien se la vende como una casilla marcada una vez le está tranquilizando, no protegiendo.

De la orientación a la acción, en la práctica

Si está a punto de poner en producción un caso de uso y quiere que aguante, el camino es corto y ordenado:

• Enganche el bloque al workflow, no a la empresa — nivel de riesgo, EIPD sí/no, etiquetas, mitigaciones, vigilancia. Cinco líneas para cada caso de uso, no un PDF para toda la empresa.
• Si hace falta una EIPD, use una con la sección de IA — opacidad, deriva, memorización, derecho al olvido. Sin esos apartados no es una evaluación de la IA, es un formulario.
• Dé una etiqueta al riesgo, no un adjetivo — un vocabulario compartido hace los casos comparables y las mitigaciones obvias.
• Ponga el humano en el proceso y la trazabilidad desde el primer día — no ralentizan el proyecto: lo hacen defendible. Son los dos controles que valen más que toda la política escrita.
• Trátela como viva — revise el modelo, la norma italiana y el perímetro de uso a intervalos, no una sola vez en el lanzamiento.

Pero, antes incluso, conviene saber dónde está: nuestra evaluación de preparación para la IA ayuda a entender por qué departamento empezar con más retorno y menos fricción, y qué controles poner alrededor del primer workflow. Es exactamente este bloque de gobernanza el que nuestro overlay de conformidad engancha a cada diseño que proyectamos — no un documento aparte, sino los controles dentro del flujo.

Hemos convertido el primer paso en una evaluación de autoservicio y gratuita: pocas preguntas y una indicación sobre por dónde empezar, con qué controles alrededor. Haga la evaluación de preparación para la IA — y si el tema es la gobernanza de un caso de uso que está a punto de adoptar, escríbanos y lo hablamos.

Este artículo tiene finalidad orientativa y no constituye asesoramiento legal. El marco normativo sobre AI Act, RGPD y ley italiana está en evolución — en particular, los plazos, el ámbito de la EIPD y las orientaciones del Garante Privacy pueden cambiar: hay que verificarlos sobre el texto vigente para el caso concreto de cada empresa.