Si en tu empresa ya estáis usando IA para responder tickets, priorizar leads, resumir reuniones o automatizar tareas “de las que nadie quiere encargarse”, el AI Act te pone una condición clara: no vale con que funcione; tiene que ser controlable, explicable y seguro para el contexto en el que lo usas. Y si quieres aterrizarlo sin frenar al equipo, en Bolmia lo trabajamos como un sistema operativo (inventario, riesgos, controles y evidencias) desde nuestro servicio de Agencia de IA.
Del “hype” a la operativa: lo que realmente cambia con el AI Act
El error típico es tratar el AI Act como un documento legal que se “pasa” al final del proyecto. En la práctica, lo que te exige es algo muy de operaciones: saber qué sistemas tienes, qué hacen, qué riesgos generan y qué controles aplicas para mantenerlos bajo control. No es filosofía. Es gobernanza aplicada al día a día.
Además, este marco te obliga a dejar de construir IA como si fuera una feature aislada. La IA toca datos, seguridad, UX, soporte, reputación y, en algunos casos, derechos y oportunidades de personas. Por eso la conversación deja de ser “¿qué modelo usamos?” y pasa a “¿qué permitimos que haga, con qué evidencias y con qué límites?”. Cuando lo enfocas así, paradójicamente ganas velocidad: menos incendios en producción, menos discusiones internas sin métricas y menos retrabajo por cambios improvisados.
Aquí es donde muchas empresas se dan cuenta de que necesitan algo más que una herramienta: necesitan proceso y responsables claros, como haría una consultoría en inteligencia artificial bien aterrizada.
Inventario: localizar la IA que ya está “en producción” sin que nadie lo admita
Antes de clasificar riesgos, hay que aceptar una verdad incómoda: casi siempre ya hay IA funcionando en rincones que nadie contabiliza. El chatbot “temporal” del soporte, el asistente que redacta propuestas comerciales, el flujo que etiqueta leads en el CRM o el equipo de RRHH usando una plataforma externa para filtrar currículums. Si no lo inventarias, no lo puedes controlar.
Un inventario útil no es un Excel eterno. Es un registro vivo, con lo justo para decidir: propósito, equipo dueño, datos que toca, canal donde actúa, nivel de autonomía, proveedor/modelo y controles actuales. Y, sobre todo, impacto: ¿a quién afecta y qué pasa si se equivoca?
Cuando se hace bien, este inventario se convierte en tu “mapa de riesgos” y en tu backlog realista. Es típico que aquí aparezcan dependencias ocultas con proveedores de inteligencia artificial que nadie había evaluado formalmente.
Clasificación práctica: un árbol de decisión que evita debates eternos
Clasificar no debería ser una pelea entre “Legal dice que no” y “Producto dice que sí”. Lo que funciona es un árbol de decisión simple y repetible. En Bolmia lo hacemos con preguntas que se responden en 20–30 minutos por caso de uso, con gente de negocio y técnica en la misma sala.
Primero: ¿el sistema decide o influye de forma relevante en decisiones sensibles (empleo, educación, crédito, acceso a servicios esenciales, seguridad, justicia)? Si la respuesta es “sí” o “puede ser”, el listón sube. Segundo: ¿interactúa con personas o genera contenido que puede confundirse con humano? Entonces entra fuerte la transparencia: avisos, límites y escalado a humano. Tercero: ¿qué daño produce un error? No es lo mismo equivocarte en el tono de un email que en una denegación de candidato.
Este enfoque evita el autoengaño del “hay un humano revisando”. Si el humano aprueba sin contexto, con prisa o por KPI, eso no es control; es un sello.
Casos que suben el riesgo sin que te des cuenta (y son más comunes de lo que parece)
Hay usos que parecen inocentes porque “solo ayudan”, pero en realidad empujan decisiones. Ejemplo clásico: IA que hace un “shortlist” de candidatos. Aunque el reclutador decida al final, el sistema ya está filtrando oportunidades. Otro: IA que puntúa leads y deja fuera perfiles que sí podrían comprar. O un asistente que recomienda límites de crédito “para ahorrar tiempo”. En cuanto una recomendación pesa más que el criterio humano, estás jugando a otra liga.
También hay riesgo cuando combinas piezas. Un modelo generativo puede ser “de bajo riesgo” aislado, pero si lo conectas a acciones (enviar, borrar, aprobar, bloquear, modificar datos) ya no es solo texto: es ejecución. Y ahí aparecen fallos tipo “el modelo inventó una política” o “mandó el mensaje al cliente equivocado”.
Este es el motivo por el que una consultora de inteligencia artificial suele insistir tanto en el diseño de flujos y permisos: el riesgo rara vez está solo en el modelo, está en la integración.
Roles y responsabilidades: quién decide qué (y cómo evitar el “esto no es mío”)
El AI Act, llevado a la práctica, te obliga a asignar ownership. Si no hay dueño, no hay control. Y si no hay control, lo normal es que el sistema se degrade: cambian los datos, cambian los prompts, cambia el contexto del negocio… y nadie sabe por qué dejó de funcionar.
Lo que funciona es definir roles por sistema, no por departamento. Producto define finalidad y límites; Data valida fuentes y calidad; Seguridad define accesos, logging y amenazas; Legal/Compliance valida clasificación y evidencia; Operaciones define monitorización e incidentes; Soporte aporta casos reales de fallo y quejas. Esta mesa evita el “pásaselo a…”.
Cuando el rol está claro, también está claro qué se aprueba y qué no. Y ahí es donde encajan perfiles externos tipo especialistas en inteligencia artificial, porque ayudan a bajar la discusión de “opiniones” a “criterios medibles”.
Controles técnicos que se notan en negocio: datos, prompts, permisos y trazabilidad
Aquí está el punto donde muchas empresas se equivocan: intentan “cumplir” con un documento, pero sin cambiar nada en la operativa. Y la operativa es lo que te salva cuando algo falla.
Si trabajas con RAG (búsqueda + generación), el primer control es la base de conocimiento: si está vieja o contradictoria, la IA responderá con seguridad… pero mal. Si haces scoring o clasificación, el control es el dataset: representatividad, sesgos, duplicados, y por qué esa etiqueta significa lo que significa. Y si usas herramientas externas, el control es el permiso: qué datos salen, qué se guarda, quién accede y durante cuánto tiempo.
Además, versiona lo que cambia comportamiento: prompts, reglas, fuentes, configuración. “Toqué un prompt” es un cambio de producto. Si no lo versionas, no podrás explicar ni reproducir errores. Esto es algo que una empresa de inteligencia artificial madura tiene interiorizado: todo cambio deja huella.
Documentación viva: el truco para que “compliance” no sea un Word muerto
La documentación no debería ser un trámite al final. Debería salir sola de tu rutina: tickets, repos, dashboards, notas de despliegue y logs. La evidencia “buena” es la que se genera mientras trabajas, no la que se inventa cuando alguien la pide.
Para cada sistema, intenta tener una ficha breve: propósito, límites, owner, datos que toca, categoría de riesgo y justificación. Súmale un registro de cambios y un pequeño resumen de pruebas: qué test haces antes de desplegar y qué monitorizas después. Y, por último, un flujo de incidentes: qué haces cuando el sistema alucina, discrimina o filtra información sensible.
Este pack mínimo te ahorra horas de pánico cuando hay auditoría, cuando un cliente reclama o cuando el equipo interno pregunta “¿por qué ahora responde distinto?”. Es el tipo de enfoque que suele aportar un partner de inteligencia artificial con mentalidad de producto y operación, no solo de demo.
Transparencia sin romper conversión: cómo decir “esto es IA” de forma inteligente
Transparencia no significa poner un disclaimer feo y ya. Significa diseñar expectativas. Un chatbot debería decir qué es, qué puede resolver y cuándo pasará con una persona. Un generador de emails debería dejar claro que el texto se revisa. Y cualquier sistema que genere contenido “muy creíble” debería tener barandillas: evitar inventar precios, políticas, garantías o condiciones. Incluso, se debe tener en cuenta diseñar políticas internas de IA que reduzcan riesgos sin matar la velocidad.
La transparencia bien hecha mejora la experiencia, porque reduce frustración. El usuario entiende por qué una respuesta es limitada y qué alternativa tiene. Además, evita el “efecto magia”: cuando algo falla, nadie se siente engañado porque el sistema nunca prometió omnisciencia.
En la práctica, funciona mucho mejor un tono humano y directo (“soy un asistente virtual”) que un lenguaje legalista. Si lo diseñas con cariño, incluso mejora el ratio de resolución en primera interacción, porque el usuario pregunta mejor y el sistema no se mete en charcos.
Supervisión humana de verdad: cuándo tiene sentido y cuándo es postureo
Decir “hay humano en el loop” no te salva si el humano no tiene tiempo, contexto ni poder real de parar el sistema. La supervisión funciona cuando el revisor sabe qué buscar, tiene criterios claros y el sistema está diseñado para facilitar esa revisión.
Una forma útil de aterrizarlo es pensar en niveles. En procesos sensibles, la IA propone y el humano decide. En procesos de bajo riesgo, la IA puede ejecutar tareas acotadas, pero con límites (no tocar datos críticos, no enviar sin validación, no actuar sin confirmación). Y el “autopiloto” solo tiene sentido en tareas repetibles, con poco impacto y con un “kill switch” real.
Si hoy tu equipo aprueba sugerencias por inercia (“porque lo dice la IA”), tu control es ficticio. Aquí es donde los expertos en IA (servicios) suelen insistir en entrenamiento por roles: no un curso genérico, sino criterios para el trabajo diario.
Monitorización e incidentes: lo que haces el día que falla (porque va a fallar)
La pregunta no es si fallará; es cuándo y cómo lo detectarás. Un sistema de IA sin monitorización es como una web sin analítica: vas a ciegas. Y cuando algo va mal, lo descubres por quejas, caídas de conversión o un post en redes.
Lo mínimo viable es medir calidad (qué porcentaje resuelve bien), seguridad (si aparece información sensible o respuestas peligrosas), y cambios de comportamiento (drift). También necesitas logs que sirvan para investigar: qué entró, qué salió, qué versión estaba activa y qué acción tomó el sistema (o qué recomendó). Y luego un runbook: si pasa X, hacemos Y; si pasa Z, escalamos a alguien con autoridad.
Ejemplo real: un asistente de soporte empieza a recomendar “reembolsos inmediatos” porque se entrenó con conversaciones donde el agente humano lo ofrecía como excepción. Si no lo detectas rápido, pierdes dinero, generas precedentes y se te rompe el margen.
Cómo elegir apoyo externo sin comprar humo (y sin depender para siempre)
Muchas empresas llegan aquí y dicen: “vale, lo montamos con un proveedor”. Perfecto… si eliges bien. La trampa es contratar a alguien que solo te vende modelo y te deja el resto en el aire. Lo que necesitas es alguien que te ayude a diseñar procesos, controles, evidencias y mantenimiento.
Pistas de buena señal: te piden inventario, definen límites, hablan de versionado, de permisos, de logs y de incidentes. Pistas de mala señal: solo hablan de “precisión”, “prompts” y “wow factor”, y evitan el tema de datos y seguridad.
Por eso conviene exigir un enfoque tipo consultora IA (en el sentido de proceso y gobernanza, no solo implementación), aunque luego ejecutes con tu equipo interno. El objetivo es que no dependas para siempre: que el sistema se quede en tu casa, con tus reglas y tu control.
Plan 30-60-90 días para aterrizarlo sin parar la compañía
Si quieres hacerlo orgánico y sin burocracia, piensa en fases. En los primeros 30 días, céntrate en visibilidad: inventario, ownership por sistema y semáforo de riesgo. En paralelo, añade límites rápidos donde más duele: evitar envíos automáticos sin revisión, limitar acceso a datos sensibles y activar logs básicos.
En 60 días, refuerza operativa: versionado de prompts y fuentes, pruebas mínimas antes de desplegar, transparencia bien diseñada y métricas que te digan si el sistema empeora. Y en 90 días, consolida evidencia: fichas por sistema, runbook de incidentes, formación por roles y un proceso claro para aprobar nuevos casos de uso sin improvisar.
Preguntas frecuentes
1) ¿El AI Act afecta si solo uso IA para tareas internas?
Sí. Aunque no “vendas” IA, si la usas para procesos que impactan decisiones, datos sensibles o atención a usuarios, debes aplicar controles y trazabilidad según el riesgo.
2) ¿Cómo sé si mi caso de uso es de alto riesgo?
Si influye en empleo, educación, crédito, servicios esenciales, seguridad o derechos, asúmelo como candidato a alto riesgo y evalúalo con criterios claros y evidencia.
3) ¿Qué significa transparencia en la práctica?
Avisar cuando se interactúa con IA, evitar que el sistema se haga pasar por humano, etiquetar contenido sintético cuando corresponda y ofrecer escalado a una persona en casos sensibles.
4) ¿Qué controles mínimos debería implementar ya?
Inventario + ownership, límites de uso, logs, versionado de cambios (prompts/datos/base de conocimiento/modelo) y un flujo de incidentes con runbook.
5) ¿Qué es lo que más suele fallar en producción?
Datos desactualizados, falta de versionado, permisos excesivos y ausencia de monitorización. La IA puede “funcionar” en demo y degradarse en semanas sin que nadie lo note.
