Política de uso de IA: las 12 secciones que tu equipo necesita (2026)

Tu equipo ya está usando IA. La pregunta no es si la vas a permitir: es si sabes con qué datos.
Y hay dos formas de que esto salga mal. La ruidosa —alguien pega la base de clientes en un chat público— es la que todos imaginan. La silenciosa es más común y más cara: la gente que no usa la herramienta porque nadie le dijo qué puede subir.
Esta segunda me la encontré de frente en una llamada de consultoría hace unos meses. Y es la que esta guía resuelve.
¿Por qué mi equipo no usa la IA que ya le di?
Estaba en videollamada con un consultor —de un despacho chico, fuera de México— mostrándole cómo procesar transcripciones de sus reuniones con un agente. Le interesaba. Y a media demo me frenó:
"Perdón la pregunta de nuevo: ¿me tengo que preocupar por la confidencialidad, por anonimizar?"
Le expliqué que dependía de cómo lo tuviera acordado con sus clientes. Lo pensó y soltó lo importante:
"No hay una normativa en general. Pero la confidencialidad de mis clientes y la sensibilidad de sus datos es algo muy importante. Yo tengo una obligación."
Ahí está el problema completo. No lo frenaba una ley. Lo frenaba no saber dónde estaba la línea. Más adelante en esa misma conversación lo dijo todavía más claro, hablando de darle acceso a un agente:
"Lo entiendo, es fascinante, pero no me animo a darle acceso a todo. No es sólo un tema de privacidad, sino de confianza."
Ese consultor no necesitaba un documento legal de 40 páginas. Necesitaba una respuesta a "¿qué puedo subir?". Sin ella, no usaba nada — y su competencia sí.
Una política de uso de IA que funciona no existe para frenar al equipo. Existe para destrabarlo. Si la tuya solo tiene prohibiciones, vas a lograr lo mismo que no tener ninguna: gente usando su cuenta personal a escondidas, o gente que no la usa.
¿Qué datos puedo subir a ChatGPT y cuáles no?
Aquí está la parte donde casi todos se equivocan, y en la llamada también pasó. La reacción instintiva es anonimizar todo.
Yo no anonimizaría todos mis datos. Y no es descuido: es que tratar todo como confidencial no protege nada y sí paraliza al equipo. Cuando toda la información es secreta, nadie sabe cuál cuidar de verdad.
La distinción que sí funciona son grados de riesgo:
No se sube tal cual: nombres de personas, correos, teléfonos, montos de contratos, nombres de clientes, cualquier cosa cubierta por un NDA. Datos que identifican a alguien.
Sí se puede subir: la estructura de un documento, la lógica de un proceso, redacción, análisis, código sin credenciales. Todo lo que no señala a una persona concreta.

Un dato importante: esto depende de dónde opera tu cliente, no de dónde operas tú. Un colega en Alemania sí tiene que anonimizar todo, porque su normativa se lo exige de forma explícita. En México y buena parte de LATAM no existe esa obligación legal — pero la obligación contractual con tu cliente sigue viva. La ausencia de ley no es un permiso.
Te dejo algo gratis para arrancar. Armé un generador de política de uso de IA: respondes 8 preguntas y te da el documento listo para copiar, adaptado a si manejas datos de clientes, si tienes NDAs y a qué tamaño de equipo. Corre en tu navegador y no guarda nada.
¿Cómo anonimizo sin perder la automatización?
Esta fue la siguiente objeción en esa llamada, y es la buena:
"Lo que creamos anonimizaba automáticamente... pero eso le saca automaticidad, ¿no?"
Tiene razón si la sustitución la hace un humano. Si alguien tiene que revisar cada documento y tachar nombres a mano, se acabó la automatización: es más trabajo que hacerlo sin IA.
La solución es que no la haga un humano ni el modelo. La hace código, antes de que el texto llegue al modelo.
Los datos identificables casi siempre tienen forma reconocible. Un correo tiene arroba. Un teléfono tiene diez dígitos. El nombre de tu cliente ya lo conoces, está en tu CRM. Todo eso se reemplaza con un script en el paso previo, y lo que llega al modelo ya viene limpio.
En esa demo lo hicimos en vivo con una carta poder: entró el documento, un paso de código sustituyó nombre, correo y teléfono, y el modelo trabajó sobre la versión sustituida. El dato real nunca pasó por ChatGPT. El proceso siguió siendo automático de punta a punta.

Esta diferencia importa más de lo que parece, y es la misma lógica que separa un agente de IA de una automatización tradicional: pedirle al modelo "por favor no guardes esto" no es un control. Que el dato nunca llegue, sí.
Cuando el documento es tan sensible que ni sustituido debe salir de tu infraestructura, la respuesta es un modelo local. Ya existen y corren en tu propio equipo. Pero es la excepción, no el default — resuelve que el dato no salga a internet, y deja intactas las preguntas de quién accede y qué se revisa.
¿Qué secciones lleva una política de uso de IA?
Doce. Cada una responde una pregunta que tu equipo se va a hacer, y por eso están redactadas como pregunta y no como título legal.

1. Qué herramientas están aprobadas. Nombre y para qué. Sin lista, cada quien elige la suya y no tienes idea de dónde vive tu información.
2. Con qué cuenta se usan. La cuenta de la empresa, no la personal. Es la sección que más se salta y la que más riesgo evita: en una cuenta personal no tienes visibilidad, ni control de retención, ni forma de saber qué se subió.
3. Qué datos nunca se suben. La lista concreta del apartado anterior. Sin ejemplos es decorativa.
4. Qué datos sí se pueden subir. La mitad que casi nadie escribe, y la que destraba. Una política que solo prohíbe frena.
5. Cómo se anonimiza. El procedimiento, no la intención. Quién corre el script, dónde vive, qué pasa si falla.
6. Qué se revisa antes de que salga. Todo lo que llega a un cliente lo lee un humano. La IA redacta, no aprueba.
7. Qué se le dice al cliente. Si usas IA con su información, se lo dices tú antes de que pregunte. En la llamada, mi regla propia fue: en el contenido público nunca aparece quién es el cliente.
8. Quién decide cuando no está claro. Un nombre. Sin dueño, cada duda se resuelve en silencio y a criterio de quien tenga prisa.
9. Qué hacer si se subió algo que no debía. Va a pasar. Sin ruta de reporte, se oculta — y un incidente oculto no se corrige.
10. Qué se registra. Qué herramienta, para qué, con qué tipo de dato. No para vigilar: para saber qué revisar cuando cambie algo.
11. Qué hacer con lo que la IA inventa. El modelo se equivoca con seguridad total. Quien manda el resultado responde por él.
12. Cuándo se actualiza esto. Cuando entre herramienta nueva o aparezca un caso que la política no cubría. Un documento que no cambia en un año mientras el equipo adoptó tres herramientas está muerto.
Que sean doce no significa cuarenta páginas. Una página bien escrita que el equipo lee vale más que un documento largo que nadie abre — es la misma lógica de las 12 reglas de un CLAUDE.md: cada línea que no cambia una decisión, sobra.
¿Por dónde empiezo si no tengo nada?
Por las secciones 1, 3 y 4. Herramientas aprobadas, qué no se sube, qué sí. Con eso ya destrabas al 80% del equipo y evitas el riesgo grande.
El resto se agrega conforme aparezcan los casos. Escribir las doce de golpe antes de que exista una sola pregunta real es cómo nacen los documentos que nadie lee.
Y una advertencia que vale más que las doce juntas: prohibir la IA no la elimina. La manda a la cuenta personal del empleado, donde no ves nada. Una política que prohíbe sin dar alternativa produce el riesgo que quería evitar, ahora invisible.
Cuando esto ya está resuelto, el siguiente paso es cómo se reparte el trabajo entre personas y agentes — eso lo cubro en la guía de operaciones para equipos humanos + agentes de IA.
Aquel consultor no tenía un problema de herramientas. Tenía un problema de permiso: nadie le había dicho dónde estaba la línea. Su conclusión al final de la llamada fue que la clave era la gente.
Le dije que la clave es el orden. Sigo pensando lo mismo.
¿Quieres armar la tuya con tu caso concreto? Si tu equipo ya usa IA sin reglas —o no la usa por miedo a meter la pata— agenda una llamada de consultoría. Son 30 minutos, sin costo: revisamos qué datos manejas y qué secciones necesitas de verdad.
Preguntas frecuentes
¿Mi empresa necesita una política de uso de IA si no hay ley que lo exija?
Sí, pero no por la ley. En México y en la mayoría de LATAM no hay una normativa que te obligue —a diferencia de Alemania, donde la regulación sí prohíbe meter datos de personas en herramientas de terceros. La razón real es otra: tu obligación de confidencialidad con tus clientes no desaparece porque la ley no la mencione. Si firmaste un NDA y subes ese contrato a un chat público, incumpliste el NDA, no una ley de IA.
¿Qué puedo subir a ChatGPT y qué no?
La regla corta: si el texto identifica a una persona o a un cliente —nombre, correo, teléfono, monto, nombre de empresa— no se sube tal cual. Se sustituye antes. Todo lo demás (estructura del documento, lógica del proceso, redacción) sí se puede. El error es tratar todo como confidencial: eso no protege nada y sí frena al equipo por completo.
¿Anonimizar no le quita lo automático al proceso?
Es la objeción más común y tiene respuesta. Si sustituyes a mano, sí: se acaba la automatización. Por eso la sustitución se hace con código, no con criterio humano ni pidiéndole al modelo que se porte bien. Los datos identificables casi siempre tienen forma reconocible —un correo tiene arroba, un teléfono tiene diez dígitos, el nombre del cliente ya lo conoces— y eso se reemplaza con un script antes de que el texto toque el modelo.
¿Sirve de algo prohibir ChatGPT en la empresa?
No. Prohibirlo no lo elimina: lo manda a la cuenta personal del empleado, donde no tienes visibilidad, ni control de retención, ni forma de saber qué se subió. Una política que prohíbe sin dar alternativa produce exactamente el riesgo que quería evitar, con la diferencia de que ahora es invisible.
¿Cada cuánto se actualiza una política de uso de IA?
Cuando cambie algo real: entra una herramienta nueva, alguien encuentra un caso que la política no cubría, o cambia la normativa de un cliente. Una política que lleva un año idéntica mientras el equipo adoptó tres herramientas nuevas está muerta. La sección de qué hacer cuando no está claro existe justo para que esos casos lleguen a alguien en vez de resolverse en silencio.
¿Un modelo local resuelve el problema de confidencialidad?
Resuelve el de que el dato salga a internet, que no es el único. Si el contrato es tan sensible que no puede salir de tu infraestructura, un modelo local es la respuesta correcta. Pero sigues necesitando reglas de quién accede, qué se guarda y qué se revisa antes de mandarlo a un cliente. La herramienta cambia el riesgo de lugar; la política es la que lo administra.
¿Te sirvió este artículo?
Recibe la siguiente táctica en tu correo.
Una guía práctica de automatización e IA cada viernes. 3,000+ founders en LATAM. Gratis.
Resume este artículo con IA

Gabriel Neuman
Consultor en Automatización e IA con más de 15 años de experiencia. Ayudo a dueños de negocios a recuperar su tiempo mediante sistemas que trabajan solos. Fundador de GNB Labs y apasionado por el NoCode.
¿Listo para automatizar tu negocio?
Ayudo a empresas a escalar mediante automatización inteligente y estrategias de IA. Sin fricción, sin complicaciones, resultados en semanas.

