Cómo Construir su Política de Uso de AI: Un Framework de 6 Secciones para CIOs y Asesores Legales

Sus empleados ya están usando AI.

No las herramientas de AI que usted ha aprobado. Las que aún no ha revisado. Las cuentas gratuitas de ChatGPT que alguien configuró el año pasado. La suscripción a Copilot que un jefe de departamento añadió al presupuesto del equipo. La extensión del navegador que tres ingenieros instalaron y que "lee su pantalla para ayudarle a escribir más rápido."

Cada una de estas herramientas está en uso activo. Cada vez que se pega un registro de cliente, una proyección financiera interna o un borrador de contrato en estas herramientas, hay una potencial exposición de datos. Y toda empresa que no tiene una política de uso de AI ha aprobado implícitamente todo eso al no decir nada. El EU AI Act requiere que las organizaciones que despliegan AI en contextos de alto riesgo tengan gobernanza documentada en lugar: el resumen de EUR-Lex sobre obligaciones de gobernanza de AI deja claro que las prácticas informales no satisfacen los requisitos de cumplimiento.

Una política no frena la adopción de AI. La hace sostenible. Da a sus empleados una guía clara sobre qué es seguro, qué requiere aprobación y qué está fuera de límites. Pueden moverse rápidamente dentro de límites conocidos en lugar de evitar la AI por completo o usarla de forma imprudente.

Este artículo le brinda la estructura completa de 6 secciones, las decisiones clave a tomar en cada sección, y referencias de políticas de proveedores reales que puede usar como anclas para su propio lenguaje.

Por qué lo necesita ahora, no después de escalar

Key Facts: El Costo de No Tener Política de AI

• El 78% de los trabajadores del conocimiento usa herramientas de AI personales en el trabajo sin aprobación explícita del empleador; la mayoría de las organizaciones no tiene visibilidad sobre qué herramientas están en uso en toda su fuerza laboral (Microsoft Work Trend Index, 2024)
• Las empresas sin políticas de gobernanza de AI enfrentan costos de violaciones de datos que promedian $4.88M por incidente bajo GDPR, comparado con un costo medio del programa de gobernanza de $50.000-100.000 para empresas del mercado medio (IBM Cost of Data Breach Report 2024)
• El EU AI Act, ahora en vigor, requiere que las organizaciones que despliegan AI en contextos de alto riesgo tengan gobernanza documentada en lugar; las prácticas informales no satisfacen los requisitos de cumplimiento (EU AI Act, vigente 2025-2026)

La brecha de gobernanza en la Etapa 1 es la fuente más común de incidentes de AI. Pero muchas organizaciones se dicen que abordarán la política "una vez que la AI esté más establecida en la empresa." Esa lógica tiene las cosas al revés.

El momento de escribir la política es antes de que ocurran los incidentes, no después. Y los incidentes están ocurriendo ahora mismo, de forma invisible.

Un abogado en una firma mediana pega un borrador de acuerdo de fusión en ChatGPT para limpiar el lenguaje. Un representante de ventas sube una hoja de cálculo de datos de contacto de clientes a una herramienta de AI para generar automáticamente correos personalizados. Un ingeniero le pide a Copilot que revise código que contiene una API key interna en los comentarios.

Ninguno de estos empleados actuó maliciosamente. Ninguno tenía orientación de política que le dijera que no lo hiciera. Ninguna de sus empresas sabe que ocurrió.

La política que usted escribe este trimestre es la política que previene que esos incidentes se conviertan en problemas mayores. También es el requisito de entrada a la Etapa 2: el modelo de madurez de AI requiere una política escrita antes de poder ejecutar un pilot gobernado. No se puede construir un programa de AI conforme sobre una base sin política.

La buena noticia: no necesita una política perfecta para comenzar. Necesita una que exista y se comparta. La iteración supera a la ausencia.

"La política que escribe este trimestre es la que previene que los incidentes se conviertan en problemas de primera plana. El programa de gobernanza que habría prevenido una violación de datos importante cuesta $50.000-100.000. Los honorarios legales, la respuesta regulatoria y la comunicación con clientes después de la violación promedian $4.88M. La matemática de la inversión en gobernanza de AI es directa." (Rework, basado en IBM Cost of Data Breach 2024)

La Plantilla de Política de AI de 6 Secciones

Un framework estructurado para construir una política de uso de AI empresarial que cubre los requisitos mínimos de cumplimiento de gobernanza, claridad para los empleados y protección legal. Las seis secciones son: (1) Uso Aceptable (herramientas aprobadas, propósitos permitidos, acceso basado en roles), (2) Reglas de Clasificación de Datos (qué niveles de datos pueden entrar en qué categorías de herramientas), (3) Proceso de Aprobación para Nuevas Herramientas (recepción, revisión, registro), (4) Herramientas y Acciones Prohibidas (líneas duras de cumplimiento y seguridad), (5) Reporte de Incidentes (canal de reporte, SLA de respuesta, protección para los reportantes), (6) Requisitos de Capacitación (línea base para todos los empleados, elevada para roles de alto acceso). Un borrador funcional que cubra las seis secciones es más valioso que un documento perfecto en desarrollo. La iteración supera a la ausencia.

Las 6 secciones requeridas

Sección 1: Uso Aceptable

Esta sección responde: qué herramientas de AI están aprobadas, para qué propósitos y para qué roles de empleados.

Decisiones clave a tomar:

Liste las herramientas aprobadas por nombre. No diga "herramientas de AI aprobadas" de forma genérica. Nómbrelas: ChatGPT Enterprise, Microsoft Copilot para Microsoft 365, Anthropic Claude for Teams, GitHub Copilot. Cada herramienta nombrada tiene un estado de aprobación: Aprobada, Aprobada Condicionalmente (con restricciones) o En Revisión.

Para cada herramienta aprobada, indique los casos de uso permitidos. "ChatGPT Enterprise: aprobada para redactar comunicaciones internas, resumir notas de reuniones y generar contenido en primer borrador. No aprobada para procesar datos de clientes ni generar documentación de cumplimiento sin revisión humana."

Defina qué roles tienen acceso a qué herramientas. No todos los empleados necesitan todas las herramientas. Su equipo de finanzas puede tener acceso a herramientas de AI que su equipo de almacén no tiene. Esta es una elección de gobernanza, no una limitación técnica.

Referencia de proveedor: Microsoft 365 Copilot es de nivel empresarial con integración del Centro de Cumplimiento de Microsoft, lo que significa que hereda su manejo de datos de Microsoft 365 existente, las políticas de prevención de pérdida de datos (DLP) y el registro de auditoría. Si su empresa ya está en Microsoft 365, Copilot tiene la menor fricción de gobernanza porque opera dentro de su entorno de cumplimiento existente.

Sección 2: Reglas de Clasificación de Datos

Esta sección responde: ¿qué datos pueden poner los empleados en herramientas de AI?

Esta es la sección más importante de la política. La mayoría de los incidentes de gobernanza de AI ocurren aquí. Un empleado usa una herramienta de AI aprobada para un propósito aprobado, pero pega los datos incorrectos.

Decisiones clave a tomar:

Defina sus niveles de datos y qué niveles están permitidos en qué categorías de herramientas. Un framework funcional:

El detalle requerido aquí se cubre completamente en Reglas de Clasificación de Datos para Acceso de AI, que debe leerse junto con esta sección de la política.

Referencia de proveedor: OpenAI Enterprise no usa sus datos para entrenar modelos, opera bajo un acuerdo de procesamiento de datos (DPA) y tiene certificación SOC 2 Type II. Eso lo convierte en un hogar apropiado para datos de nivel Interno. Anthropic Claude for Business ofrece de manera similar compromisos de no entrenamiento y opciones de residencia de datos. El punto clave: verifique estos compromisos en el acuerdo empresarial real antes de tratarlos como autorizados por política.

Una brecha común: Políticas que dicen "no use AI con datos sensibles" sin definir qué significa sensible. Los empleados interpretan "sensible" para significar casos extremos (registros médicos, números de seguridad social) y no se dan cuenta de que las direcciones de correo electrónico de clientes, los términos contractuales o los números de ingresos internos también son sensibles según los estándares de la mayoría de las empresas.

Sección 3: Proceso de Aprobación para Nuevas Herramientas

Esta sección responde: ¿cómo puede un empleado obtener que se evalúe y apruebe una nueva herramienta de AI antes de su uso?

Sin un proceso de aprobación, tiene tres resultados: los empleados usan herramientas no aprobadas de todos modos (shadow AI), los empleados no usan AI en absoluto (adopción bloqueada), o IT aprueba todo de forma reactiva cuando alguien recibe una factura. Ninguno de estos es gobernanza.

Decisiones clave a tomar:

Defina el proceso de recepción. Un formulario simple funciona: nombre de la herramienta, proveedor, caso de uso previsto, tipos de datos a procesar, costo, quién la solicitó. Esto debería tomar al solicitante cinco minutos completar.

Nombre al revisor. Una persona, no un comité. Para la mayoría de las empresas, este es el CIO, el CISO o su delegado. El revisor verifica los términos de manejo de datos de la herramienta, la disponibilidad del DPA, el estado del SOC 2 y la alineación con sus reglas de clasificación de datos.

Establezca un estándar de tiempo de respuesta. Cinco días hábiles para solicitudes estándar. Diez días si se necesita revisión legal. Esto señala que el proceso de aprobación es receptivo, no un mecanismo de veto.

Construya un registro de herramientas. Una hoja de cálculo simple o una página de intranet que liste todas las herramientas aprobadas, sus condiciones y la fecha de la última revisión. Cuando el registro es visible para los empleados, pueden autoatenderse en lugar de enviar solicitudes redundantes.

Nota sobre alineación con NIST: El NIST AI Risk Management Framework (AI RMF) incluye una función GOVERN que establece las estructuras, procesos y equipos que las organizaciones necesitan antes de que la gestión de riesgos de AI pueda funcionar. Su función MAP cubre específicamente la identificación de los usos de AI organizacionales y sus perfiles de riesgo. Un proceso de aprobación con un registro de herramientas es la implementación práctica de ambas recomendaciones.

Sección 4: Usos Prohibidos

Esta sección responde: ¿cuáles son las líneas duras?

Los usos prohibidos se dividen en dos categorías: herramientas prohibidas y acciones prohibidas.

Herramientas prohibidas (ejemplos):

• Herramientas de AI de nivel consumidor gratuitas para cualquier trabajo de propósito empresarial (sin DPA, manejo de datos desconocido)
• Herramientas de AI de proveedores sin una ruta de acuerdo empresarial disponible
• Extensiones del navegador que acceden o modifican contenido en sus aplicaciones empresariales sin revisión de IT

Acciones prohibidas (ejemplos):

• Usar AI para tomar decisiones finales sobre contratación, promoción o rendimiento sin revisión humana y documentación
• Usar AI para generar asesoramiento legal, determinaciones de cumplimiento o presentaciones regulatorias sin revisión de un abogado
• Ingresar PII de clientes en cualquier herramienta de AI externa sin un DPA activo
• Usar AI para generar comunicaciones que afirmen ser de un humano cuando no lo son, en cualquier contexto regulado
• Ingresar materiales de M&A, materiales de directorio u otra información material no pública en herramientas de AI externas

La lista de acciones prohibidas es donde sus equipos legal y de cumplimiento tendrán más aportaciones. Preste atención a los requisitos regulatorios específicos de su industria. Las organizaciones de salud tienen restricciones de HIPAA. Las firmas de servicios financieros tienen consideraciones de FINRA y SEC. Las firmas de abogados tienen reglas de conducta profesional sobre datos de clientes. Estos pisos regulatorios pertenecen a las acciones prohibidas, no solo como orientación informal.

Una brecha común: Políticas que no listan ningún uso prohibido ("use su juicio") o políticas que listan usos prohibidos tan exhaustivamente que casi todo uso práctico de AI está bloqueado, llevando la adopción a la clandestinidad. El objetivo es especificidad sobre los riesgos reales, no restricción exhaustiva.

Sección 5: Reporte de Incidentes

Esta sección responde: ¿qué sucede cuando algo sale mal?

Los incidentes de AI son más diversos que los incidentes de seguridad tradicionales. Incluyen: una herramienta de AI que envía información incorrecta a un cliente, una exposición de datos a través del comportamiento inesperado de una herramienta aprobada, outputs discriminatorios de un sistema de AI, y contenido generado por AI incorrecto que llega a una audiencia externa.

Decisiones clave a tomar:

Defina qué constituye un incidente de AI. Dé ejemplos. "Si una herramienta de AI envía una comunicación a un cliente que usted no revisó. Si una herramienta de AI parece haber accedido o retenido datos que usted no pretendía compartir. Si un output de AI causa una queja de un cliente o una preocupación reputacional. Si una herramienta de AI produce un output que podría ser discriminatorio o perjudicial."

Nombre el canal de reporte. Un contacto: el CIO, el CISO o una dirección dedicada de gobernanza de AI. Los empleados deben poder reportar en 30 segundos, no navegar por un sistema complejo.

Establezca el SLA de respuesta. ¿Cuál es el tiempo de acuse de recibo? ¿Quién investiga? ¿Quién decide si se requiere divulgación externa (notificación al cliente, aviso regulatorio)? Para incidentes de exposición de datos, aplican sus procedimientos existentes de respuesta a violaciones. Los incidentes de AI que pueden constituir violaciones de datos bajo GDPR o CCPA necesitan seguir esos plazos.

Aclare que el reporte está fomentado, no penalizado. Si los empleados temen reportar incidentes de AI, los incidentes se acumulan de forma invisible. La política debe indicar explícitamente que el reporte de buena fe está protegido.

Una brecha común: Ninguna sección de reporte de incidentes en absoluto. Muchas políticas de AI cubren el uso aceptable y las restricciones de datos pero dejan la respuesta a incidentes sin definir. Esta es la brecha que convierte incidentes menores en mayores. Los empleados no reportan problemas que no saben cómo escalar, y las pequeñas exposiciones se acumulan.

Sección 6: Requisitos de Capacitación

Esta sección responde: ¿quién necesita completar capacitación en alfabetización de AI antes de usar las herramientas aprobadas?

Las herramientas de AI producen outputs pobres o riesgosos cuando se usan sin contexto sobre sus limitaciones. Un empleado que entiende que la AI puede producir con confianza información incorrecta revisará los outputs de AI de manera diferente a quien los trata como hechos confiables. La capacitación es mitigación de riesgos, no verificación de cumplimiento.

Decisiones clave a tomar:

Defina los requisitos de capacitación por rol y herramienta. No todos necesitan la misma capacitación. Un coordinador de marketing que usa Copilot para borradores iniciales de correos necesita una capacitación diferente a la de un analista de datos que usa AI para generación de SQL.

Establezca una línea base mínima para todos los empleados: qué es (y qué no es) la AI, qué significan en la práctica las reglas de clasificación de datos de la empresa, cómo reconocer un incidente de AI y cómo reportarlo. Esta capacitación de línea base debería tomar menos de dos horas y puede entregarse de forma asíncrona.

Para empleados con acceso elevado a AI (ingenieros que construyen flujos de trabajo de AI, líderes de equipo que gestionan herramientas de AI, cualquier rol que use AI con capacidad Execute), requiera capacitación más profunda sobre el comportamiento específico de la herramienta, sus limitaciones y modos de fallo.

Defina la cadencia de renovación. Las herramientas de AI cambian más rápido de lo que los ciclos de capacitación anuales pueden seguir. Requiera acuse de recibo de cualquier actualización material de política (nuevas herramientas aprobadas, nuevos usos prohibidos) cuando se revise la política.

Referencias de políticas de proveedores como anclas

Al negociar acuerdos de AI empresariales, estos tres puntos de referencia establecen la línea base desde la cual su organización debe negociar.

OpenAI Enterprise: Proporciona un DPA formal, se compromete a no usar sus datos para el entrenamiento de modelos, mantiene la certificación SOC 2 Type II y ofrece un proceso de revisión de seguridad dedicado. El acuerdo empresarial le da a su equipo legal un punto de partida para los términos de procesamiento de datos. Consulte OpenAI Enterprise para la documentación actual de seguridad y privacidad.

Anthropic Claude for Business: Ofrece compromisos de no entrenamiento sobre datos empresariales, opciones de residencia de datos y aislamiento de datos de nivel empresarial. La Política de Uso Aceptable de Anthropic define las categorías de contenido que sus modelos producirán y no producirán, lo que debe informar su propia lista de usos prohibidos. La documentación de política actual está en anthropic.com/legal.

Microsoft Copilot para Microsoft 365: Opera dentro del límite de cumplimiento de Microsoft 365, lo que significa que las políticas de DLP existentes, las etiquetas de retención y el registro de auditoría aplican a las interacciones de Copilot. Para organizaciones que ya están en el ecosistema de cumplimiento de Microsoft 365, este es el camino de menor fricción hacia una herramienta de AI empresarial con manejo de datos auditable. Consulte Microsoft 365 Copilot para la documentación de cumplimiento actual.

Estas referencias le dan posiciones de negociación defendibles. "Requerimos SOC 2 Type II y un DPA con compromiso de no entrenamiento" es una solicitud estándar que los tres proveedores anteriores pueden satisfacer. Los proveedores que no puedan satisfacer estos requisitos deben ajustarse por defecto a sus restricciones de nivel Confidencial.

Brechas de política que crean más riesgo

Basado en la sección de gobernanza del modelo de madurez de AI, estas son las brechas que producen más incidentes.

Sin clasificación de datos en la política. La más común y la más peligrosa. Sin orientación explícita sobre qué datos pueden ir a dónde, los empleados recurren a su intuición, que varía ampliamente. La clasificación de datos es la sección individual más impactante para acertar.

Sin mecanismo de reporte de incidentes. Los incidentes se acumulan en silencio. Las pequeñas exposiciones de datos que podrían haberse abordado temprano se convierten en problemas mayores. Toda política de AI necesita un contacto nombrado y una ruta de reporte definida.

Sin proceso de aprobación para nuevas herramientas. El shadow AI se expande al ritmo del marketing de los proveedores. Sin un proceso de aprobación, cada nueva herramienta que recibe una reseña positiva en una conferencia se convierte en una potencial responsabilidad.

Lista de usos prohibidos que bloquea todo uso práctico de AI. Políticas escritas por equipos que se preocupan principalmente por el riesgo, sin aportaciones de los equipos que necesitan usar AI para trabajar. El resultado lleva la adopción a la clandestinidad, que es peor que el riesgo que la política intentaba prevenir.

Sin cadencia de revisión. Una política escrita en 2024 que no ha sido actualizada desde entonces no aborda las herramientas que los empleados están usando hoy. La revisión trimestral de la lista de herramientas aprobadas es el mínimo. La revisión completa anual de la política debe ser un evento en el calendario.

Rework Analysis: Basado en los patrones de fracaso de gobernanza a través del framework de los 5 Modos de Fracaso de la Transformación con AI, la sección de clasificación de datos (Sección 2 de la Plantilla de Política de AI de 6 Secciones) es el elemento de política individual más determinante. Las organizaciones que definen los niveles de datos y los mapeos de herramientas por nivel de forma explícita reducen los incidentes de exposición de datos relacionados con AI al eliminar la ambigüedad que causa la mayoría de las infracciones. La mayoría de los incidentes no son causados por empleados maliciosos. Son causados por empleados que no sabían que la regla aplicaba a su situación específica. La clasificación explícita de datos elimina la ambigüedad.

Cómo aplicar sin crear fricción

La aplicación de mano dura crea el mismo resultado que no tener política: shadow AI. El enfoque de aplicación que funciona combina procesos ligeros con responsabilidad visible.

Un registro de herramientas que sea realmente accesible. Los empleados pueden verificar si una herramienta está aprobada sin enviar una solicitud. Una hoja de cálculo compartida con el nombre de la herramienta, el estado, los usos permitidos y la fecha de la última revisión, actualizada trimestralmente, reduce sustancialmente la fricción.

Tiempos de respuesta de aprobación rápidos. Un tiempo de respuesta de cinco días para solicitudes de nuevas herramientas significa que los empleados no sortean el proceso por impaciencia.

Verificaciones puntuales en lugar de monitoreo exhaustivo. Revisión trimestral de facturas de herramientas de AI e informes de gastos para detectar herramientas no aprobadas en uso. No vigilancia; responsabilidad.

Responsabilidad del manager. Los jefes de departamento saben qué herramientas de AI están usando sus equipos. Hacer visible la lista de herramientas aprobadas y enviar una actualización trimestral garantiza que estén equipados para aplicarla sin microgestión.

La cadencia de revisión de la política

La tecnología de AI cambia más rápido que la IT tradicional. Una política escrita en enero puede estar materialmente desactualizada para julio: nuevas herramientas lanzadas, términos de proveedores cambiados, orientación regulatoria emitida. Incorpore la cadencia de revisión en la política misma.

Trimestralmente: Revise la lista de herramientas aprobadas. Añada herramientas recién revisadas. Elimine o restrinja herramientas cuyos términos de proveedor hayan cambiado. Registre los incidentes del trimestre anterior y evalúe si se necesitan actualizaciones de política.

Anualmente: Revisión completa de la política. Evalúe si los niveles de clasificación de datos aún reflejan los tipos de datos empresariales actuales. Actualice los ejemplos de usos prohibidos. Revise los requisitos de capacitación según lo que ha cambiado.

Basado en disparadores: Cualquier incidente material de AI, cualquier cambio significativo en los términos de manejo de datos de los proveedores, cualquier nueva orientación regulatoria que afecte a su industria. No espere el ciclo trimestral cuando un evento disparador requiere una respuesta inmediata.

La estructura de la política, en resumen

Una política de uso de AI que cumple su función tiene estas seis secciones:

1. Uso Aceptable: Herramientas aprobadas, propósitos permitidos, acceso basado en roles
2. Reglas de Clasificación de Datos: Qué datos pueden ir en qué categorías de herramientas
3. Proceso de Aprobación: Cómo se evalúan y registran las nuevas herramientas
4. Herramientas y Acciones Prohibidas: Líneas duras de cumplimiento y riesgo
5. Reporte de Incidentes: Cómo reportar, quién responde, qué está protegido
6. Requisitos de Capacitación: Línea base para todos los empleados, elevada para roles de alto acceso

Imprima esta lista. Compártala con su asesor legal y su CISO. Reserve medio día para redactar la primera versión. Un borrador funcional publicado internamente hoy es más valioso que una política perfecta entregada en seis meses.

La pregunta más difícil no es cómo escribir la política. Es qué sucede cuando ocurre el primer incidente y descubre si la política realmente funcionó.

Qué leer a continuación

Lea: Reglas de Clasificación de Datos para Acceso de AI para el framework completo de 4 niveles que requiere la Sección 2 de esta política.

Lea: Puertas de Aprobación de AI y Revisión de Proveedores para la lista de verificación completa de evaluación de proveedores referenciada en la Sección 3.

Lea: Playbook de Respuesta a Incidentes de AI para el runbook del que depende la Sección 5.

Lea: Etapa 1 a 2: De Ad-Hoc a Piloto para ver cómo la política encaja en los requisitos de la Etapa 2 y por qué es el requisito de entrada al pilotaje gobernado.

Vea también:

• Trazas de Auditoría para Acciones Execute de AI: los requisitos de registro que fluyen directamente de la sección de reporte de incidentes de su política
• La Frontera Generate vs. Execute: Por Qué Importan las Medidas de Seguridad: la distinción que su lista de usos prohibidos necesita codificar
• Por Qué Fracasan la Mayoría de las Transformaciones con AI: cómo la ausencia de gobernanza es una de las cinco causas raíz