La IA se está colando en las empresas por la puerta grande… y por la de atrás. Un equipo la usa para redactar emails, otro para resumir tickets, producto para prototipar features y ventas para preparar propuestas. Todo suena eficiente hasta que, de repente, alguien pega una lista de clientes en una herramienta no aprobada, un bot responde con seguridad algo inventado o una automatización toma una decisión que nadie puede explicar. Por eso una política interna de IA no debería ser un documento “para cumplir”, sino una guía viva para trabajar mejor y más seguro. Y ojo con esto: si necesitas apoyo para aterrizarlo bien desde el minuto uno, en Bolmia lo hacemos como Agencia de IA.
La clave es simple: si tu política frena al equipo, el equipo la esquiva. Si tu política acompaña al equipo, el equipo la adopta. Y en IA, adopción sin control es riesgo; control sin adopción es teatro. En este post vamos a construir una secuencia práctica para que tu política sea operativa, entendible y medible, sin convertir a tu empresa en una oficina de trámites.
La diferencia entre “política” y “operación”: lo que realmente evita incidentes
Una política interna funciona cuando se nota en el día a día. No porque la gente la cite, sino porque cambia hábitos: qué herramienta se usa, qué datos se comparten, cómo se valida lo que sale del modelo y quién tiene que dar el OK cuando algo es sensible. Si lo que tienes es un PDF que empieza con “propósito” y termina con “sanciones”, probablemente nadie lo lea y, peor aún, no cambiará nada.
En la práctica, lo que te protege es la operación: permisos, trazabilidad, checklist de datos, guías de prompts, procesos de aprobación y un plan de incidentes. El documento es solo el envase. El contenido real es el “cómo trabajamos”.
Esto es especialmente importante porque la IA tiene una característica tramposa: parece segura incluso cuando está equivocada. Un humano duda, un modelo “afirma”. Si tu política no contempla esa dinámica, te expones a errores que se propagan rápido: un dato inventado llega a un cliente, un resumen incorrecto entra en un informe, una recomendación sesgada se convierte en criterio de equipo.
Antes de escribir reglas, dibuja el mapa: inventario de usos y de datos
El primer error típico es empezar por las prohibiciones sin saber qué está pasando. En casi cualquier empresa mediana, hay usos “oficiales” y usos “fantasma”. Lo oficial: “tenemos un chatbot en la web”. Lo fantasma: extensiones del navegador, cuentas personales, herramientas gratuitas, prompts con datos reales, automatizaciones que empujan info a un CRM. Y no es porque la gente sea mala; es porque la IA resuelve problemas rápido y el negocio premia la velocidad.
Por eso, el primer paso de una política útil es crear un inventario de casos de uso con un mínimo de detalle: qué proceso se está mejorando, quién lo usa, qué herramienta/modelo interviene, qué datos entran y qué datos salen. En ese momento aparecen patrones. Por ejemplo: marketing usa datos públicos y no hay drama; soporte toca datos personales; ventas mezcla información de clientes con estrategia interna; RRHH tiene datos sensibles. De golpe, te das cuenta de que no necesitas “una política para todo igual”, sino niveles.
Ese inventario también te ayuda a decidir si necesitas apoyo externo tipo consultora de IA para bajar el caos a un sistema: no es por postureo, es por ahorro de tiempo y por evitar que el equipo técnico se coma un marrón que en realidad es de gobernanza.
Clasifica por impacto: la manera más rápida de gobernar sin bloquear
Aquí es donde muchas políticas pasan de “compliance” a “productividad”. En vez de tratar todos los casos como si fueran críticos, los clasificas por impacto y exiges controles proporcionales. Un uso de IA para generar ideas de copy no puede tener el mismo nivel de aprobación que un sistema que sugiere acciones sobre el CRM o que responde a clientes.
Una clasificación que suele funcionar (y que se entiende fácil) se basa en dos variables: tipo de datos y tipo de acción. Si no hay datos sensibles y no se ejecutan acciones, el riesgo es bajo. Si hay datos sensibles o hay salida directa al cliente, el riesgo sube. Si además el sistema puede ejecutar acciones (crear, modificar, enviar), ya estamos en riesgo alto.
Este enfoque te evita caer en el “todo prohibido” y también en el “todo vale”. Y lo mejor: ayuda a que la política sea orgánica, porque cada parte del texto responde a una pregunta natural del equipo: “¿esto en qué nivel cae y qué tengo que hacer?”.
La regla de datos: lo que nunca se pega en un prompt (y por qué)
Si tu política solo tuviera una sección, esta debería ser la de datos. La mayoría de sustos con IA no vienen de “Skynet”, vienen de personas copiando y pegando. Y como pegar datos en una caja de texto parece inocente, se hace sin pensar.
Aquí no sirve la ambigüedad. Tienes que decir claramente qué datos no deben entrar en herramientas no aprobadas: información personal identificable, datos de salud, finanzas, credenciales, contratos, información estratégica (roadmaps, precios, acuerdos), y cualquier cosa que te dolería ver publicada. Y no te quedes en categorías: incluye ejemplos cotidianos que tu equipo reconozca. Un ejemplo real: “Oye, pásame este Excel con emails y nombres y que me lo agrupe por país”. Ese gesto aparentemente simple puede ser una filtración en potencia si se hace en la herramienta equivocada.
Luego viene la parte adulta: definir qué herramientas están aprobadas para qué niveles de datos, y bajo qué condiciones. Aquí es donde a veces conviene tener una consultoría de inteligencia artificial que conecte legal, seguridad y tecnología, porque el lío no es “qué herramienta mola”, sino qué contratos, retención, auditoría y control de acceso tienes.
Seguridad real: permisos, logs y guardrails (sin convertirlo en un proyecto eterno)
En IA, “seguridad” no es solo la palabra bonita para el auditor. Es, literalmente, evitar que tu sistema haga cosas que no debería. Si la IA solo genera texto y alguien lo revisa antes de enviarlo, el riesgo es limitado. Pero si la IA está conectada a herramientas (CRM, email, helpdesk) y puede ejecutar acciones, el riesgo se multiplica. Hay algunas ventajas y riesgos de usar IA en la gestión de clientes.
Por eso tu política debe aterrizar tres ideas: control de acceso, trazabilidad y límites de ejecución. Control de acceso significa que no todo el mundo debería poder usar todas las integraciones ni tocar datos sensibles sin permisos. Trazabilidad significa que, si algo pasa, puedas reconstruir qué prompt se usó, qué versión del flujo estaba activa, qué datos entraron y qué salió. Límites de ejecución significa que el sistema no debería tener poderes absolutos: que solo pueda hacer ciertas acciones, con validaciones y, si hace falta, con confirmación humana.
La palabra “guardrails” suena a moda, pero en la práctica es puro sentido común. Es el equivalente a poner barandillas cuando tienes un balcón: no impide disfrutar la vista; evita caerte.
Calidad y “alucinaciones”: cómo evitar que tu IA se convierta en un generador de confianza falsa
A diferencia del software tradicional, la IA puede fallar sin romperse. No da error 500; te da una respuesta plausible… incorrecta. Y esa es la trampa. Por eso tu política debe incluir cómo se valida lo que sale del modelo y qué pasa cuando el modelo no sabe.
En atención al cliente, por ejemplo, el “no sé” es más sano que inventar. El problema es que muchos chatbots se configuran para “responder siempre”. Resultado: se inventan políticas, plazos, precios o condiciones. Es el típico caso de web que “atiende” pero no convierte porque genera desconfianza. La solución no es prohibir el bot, es exigir mecanismos de calidad: respuestas con base en fuentes internas, escalado a humano cuando faltan evidencias, y revisión periódica de conversaciones.
Si la IA se usa internamente (resúmenes, informes, propuestas), el riesgo se mueve: no es reputacional directo, pero sí operativo. Un resumen mal hecho puede llevar a decisiones malas. Por eso conviene que tu política obligue a una revisión humana proporcional al impacto y a tener tests básicos: una batería de preguntas frecuentes, escenarios raros y casos sensibles.
Aquí muchos equipos evolucionan cuando trabajan con una empresa de inteligencia artificial que instala un sistema de evaluación continua en lugar de “lanzar y rezar”. No hace falta complicarse como una big tech, pero sí tener un mínimo de control.
Sesgos y decisiones: la regla “recomienda, no decide” como punto de partida
Hay un salto enorme entre usar IA para productividad y usar IA para decidir. Y muchas empresas cruzan ese salto sin darse cuenta. Empiezas con “prioriza leads” y acabas con “descarta estos perfiles”. Empiezas con “recomienda descuentos” y terminas con “aplica automáticamente”. Ahí la política tiene que poner límites claros.
Una regla que suele funcionar es: la IA recomienda, el humano decide. Al menos en niveles medio y alto. Y si vas a automatizar, que sea con límites: umbrales, validaciones y capacidad de reversión. El objetivo no es desconfiar por deporte, es reconocer que los modelos aprenden patrones de datos históricos, y esos datos pueden tener sesgos. Si no lo vigilas, la IA los amplifica.
Esto no se resuelve con frases tipo “no discriminaremos”. Se resuelve con práctica: revisar outputs por segmentos, detectar patrones raros, y tener un mecanismo de reporte interno para cuando alguien vea algo sospechoso. Un partner de IA con experiencia te puede ayudar a montar esas pruebas sin perderte en teoría.
Proveedores y herramientas: comprar IA sin comprar dependencia
Otro punto donde las políticas fallan es en la selección de herramientas. No porque elijan mal, sino porque no definen criterios. Así que cada equipo compra lo suyo. Y cuando quieres ordenarlo, ya es tarde: hay procesos críticos montados sobre herramientas que no tienen logs, no tienen control de acceso o no sabes dónde guardan los datos.
Tu política debería describir un proceso ligero de aprobación de herramientas: no un comité eterno, sino un checklist rápido. Lo importante: retención de datos, entrenamiento con tus datos (si se puede desactivar), subprocesadores, jurisdicciones, exportabilidad de logs, y plan de salida. Porque si mañana cambian condiciones o precios, necesitas poder migrar.
Aquí se nota la diferencia entre “usar herramientas” y operar como compañía de soluciones de IA: en el segundo caso, la herramienta es un medio, no una cárcel.
Gobernanza: poner dueños sin crear burocracia
Si nadie es dueño, nadie responde. Y en IA, la falta de dueño crea el cóctel perfecto: el modelo falla, el negocio sufre y todos se miran. Por eso necesitas un esquema simple de responsabilidades: quién define el objetivo, quién implementa, quién valida datos/seguridad, y quién aprueba en casos sensibles.
No hace falta inventar la rueda. Un RACI básico funciona si está conectado al inventario de usos y a los niveles de impacto. Para un uso de bajo impacto, el líder del equipo puede aprobar. Para uno de impacto medio, necesita revisión técnica y de datos. Para uno de alto impacto, entra legal/compliance. El secreto es que el equipo lo vea como un camino, no como un muro. Si el proceso tarda meses, lo esquivarán.
En Bolmia solemos bajar esto a un flujo simple en Notion/Confluence con plantillas y un canal de “consulta rápida”. Lo que mata a la gobernanza no es la exigencia; es la fricción innecesaria.
Formación y cultura: la política se “instala” con hábitos, no con un email
Enviar la política por correo es como mandar un manual de gimnasio y esperar que alguien se ponga fuerte. La adopción real ocurre cuando el equipo integra hábitos: pedir aprobación cuando toca, anonimizar datos antes de usar herramientas, revisar outputs antes de enviarlos, usar prompts con estructura, y reportar incidentes sin miedo.
La formación no tiene que ser una charla de dos horas. Puede ser por roles y en formato práctico. Marketing: cómo usar IA sin meter datos sensibles y cómo validar claims. Soporte: cómo usar una base de conocimiento y cuándo escalar. Ventas: cómo redactar propuestas sin filtrar info. Producto/IT: cómo montar guardrails, logs y permisos. Y sobre todo: enseñar con ejemplos de la vida real, porque ahí es donde la gente entiende el “por qué”.
Plan de incidentes: qué pasa cuando algo sale mal (porque pasará)
Una política madura asume que habrá incidentes. No porque seas incompetente, sino porque estás operando un sistema probabilístico con humanos alrededor. Lo importante no es “que nunca pase”, sino “qué haces cuando pasa”.
Aquí el documento debe tener un playbook simple: qué se considera incidente (filtración, respuesta errónea grave, sesgo, acceso indebido), quién se activa, cómo se pausa el sistema (un kill switch real), cómo se investiga (logs, versiones, inputs), y cómo se comunica. Lo más común es que las empresas tengan una respuesta improvisada, y esa improvisación es la que convierte un error en crisis.
Un ejemplo muy típico: un asistente conectado al CRM interpreta mal una instrucción y empieza a modificar registros. Si no hay límites, puede causar un destrozo. Si hay permisos restringidos, validación y registro de cambios, el daño se contiene y se revierte. Esa diferencia no es “más IA”, es mejor operación.
Cómo escribir tu política en una estructura que el equipo sí use
Ahora, aterrizamos en algo práctico: cómo escribirla para que se use. Lo que funciona suele tener una narrativa clara, no capítulos burocráticos. Empieza por el “por qué” (breve), sigue por el inventario y los niveles (la brújula), pasa por la regla de datos (lo crítico), luego seguridad y calidad (el día a día), y cierra con gobernanza e incidentes (la red de seguridad). Si además incluyes ejemplos, tu política se vuelve casi un mini manual de trabajo.
Y aquí viene un truco que evita que quede “esquematizado”: escribe en forma de decisiones. En lugar de listas infinitas, frases tipo “si tu caso de uso toca datos personales, entonces…”. “Si el sistema responde a clientes, entonces…”. “Si puede ejecutar acciones, entonces…”. Eso se siente orgánico porque se parece a cómo piensa el equipo cuando está trabajando.
Implementación sin drama: 30-60-90 días para pasar de caos a control
El plan de implementación también debería estar dentro del documento (o como anexo), porque la política sin implementación es un propósito. En los primeros 30 días, lo más valioso es ordenar: inventario, niveles, herramientas aprobadas y regla de datos. Es lo que corta el riesgo más grande: el uso descontrolado.
Entre el día 31 y 60, metes control operativo: permisos, logs, entornos, pruebas mínimas y flujo de aprobación. Aquí se nota el cambio: el equipo puede usar IA con más confianza porque sabe que hay red.
Entre el día 61 y 90, escalas: mejoras automatizaciones, haces revisiones periódicas, montas formación por roles y haces un simulacro de incidente. Sí, un simulacro. Porque el día que pase algo real, lo agradecerás.
Cierre
Una política interna de IA que funciona no se mide por lo bonita que es, sino por lo que cambia: menos “usos fantasma”, menos datos pegados donde no toca, más trazabilidad, más calidad y menos sustos. Si tu empresa ya está usando IA, la pregunta no es si necesitas una política; es si quieres diseñarla tú a base de incidentes o diseñarla con intención, antes de que te obligue la realidad. Cuando lo haces bien, no frenas la innovación: la vuelves sostenible. Y eso, a largo plazo, vale más que cualquier demo.
Preguntas frecuentes sobre políticas internas de IA
1) ¿Qué debe tener una política de IA para que el equipo la use?
Pocas reglas, ejemplos reales, niveles de impacto y un proceso claro para aprobar casos sensibles sin burocracia.
2) ¿Cuál es el mayor riesgo en el día a día?
La fuga de datos por copy/paste en herramientas no aprobadas y las respuestas inventadas que parecen seguras.
3) ¿Cómo evito que un bot “alucine” frente a clientes?
Base de conocimiento, respuestas con fuentes, umbral de confianza y escalado a humano cuando no haya evidencia.
4) ¿Cuándo es obligatorio el “humano al mando”?
Cuando hay datos sensibles, decisiones relevantes, impacto legal o acciones automáticas sobre sistemas (CRM, email, tickets).
5) ¿Cómo apruebo nuevas herramientas sin frenar?
Checklist ligero: retención, entrenamiento con datos, subprocesadores, control de accesos, logs y plan de salida.
