Plantilla de Política de Shadow AI para Industrias Reguladas

La mayoría de las políticas de uso aceptable de IA fracasan. Son tan vagas que los empleados las ignoran, o tan restrictivas que los empleados las evitan. De cualquier manera, la organización obtiene el peor resultado: existe una política, nadie la sigue, y la dirección asume que el problema está resuelto.

Este artículo proporciona una plantilla de política completa y práctica que las organizaciones reguladas pueden adaptar y desplegar. Está diseñada para salud, servicios financieros, legal y otras industrias donde los errores de manejo de datos tienen consecuencias regulatorias. Cada sección incluye el razonamiento detrás de ella, porque una política que nadie entiende es una política que nadie sigue.

Por Qué la Mayoría de las Políticas de IA Fracasan

Antes de la plantilla, entendamos qué sale mal.

Problema 1: Escrita por legal, no por operaciones. Las políticas redactadas exclusivamente por asesores legales tienden a prohibir todo lo que conlleva riesgo. Como todo uso de IA conlleva algún riesgo, el resultado es una prohibición de facto envuelta en lenguaje cuidadoso. Los empleados la leen como "no quieren que usemos IA" y proceden a usar IA de todos modos, solo sin decirle a nadie.

Problema 2: Sin alternativas aprobadas. Una política que dice "no uses ChatGPT" sin decir "usa esto en su lugar" es inútil. Los empleados necesitan herramientas de IA. Si la política no aborda esa necesidad, los empleados la abordarán ellos mismos.

Problema 3: Sin guía de clasificación de datos. "No pongas datos sensibles en herramientas de IA" deja a los empleados adivinando qué cuenta como sensible. ¿Es un resumen de reunión interna sensible? ¿Un borrador de email? ¿Un cronograma de proyecto? Sin guía específica, los empleados tratan todo como sensible (y usan herramientas de IA de todos modos porque la restricción se siente irrazonable) o no tratan nada como sensible.

Problema 4: Crear y olvidar. Las herramientas de IA evolucionan mensualmente. Una política escrita en enero está desactualizada para marzo. Sin un calendario de revisión, la política se desconecta cada vez más de la realidad.

La plantilla a continuación aborda cada uno de estos fracasos.

---

Sección 1: Alcance y Definiciones

1.1 Propósito

Esta política gobierna el uso de herramientas de inteligencia artificial por todos los empleados, contratistas y agentes terceros actuando en nombre de [Nombre de la Organización]. Establece reglas sobre qué herramientas de IA pueden usarse, qué datos pueden procesarse a través de ellas y cómo se monitorea y aplica el uso.

1.2 Alcance

Esta política aplica a:

• Todo software con IA, incluyendo modelos de lenguaje grandes (ChatGPT, Claude, Gemini, etc.), asistentes de código (GitHub Copilot, Cursor, etc.), generadores de imágenes y funcionalidades de IA integradas en software existente
• Uso en dispositivos propiedad de la empresa, dispositivos personales usados para trabajo y cualquier red o conexión a internet al procesar datos de la empresa
• Tanto uso directo de herramientas de IA como uso indirecto a través de servicios de terceros que incorporan procesamiento de IA

1.3 Definiciones

---

Sección 2: Herramientas Aprobadas y Proceso de Solicitud

2.1 Herramientas de IA Aprobadas

El Comité de Gobernanza de IA mantiene una lista de herramientas aprobadas (Apéndice A), actualizada trimestralmente. Cada herramienta aprobada incluye:

• Niveles de datos permitidos (qué datos pueden procesarse)
• Casos de uso aprobados (para qué puede usarse la herramienta)
• Tipo de cuenta requerido (licencia corporativa vs. cuenta personal)
• Cualquier restricción específica de la herramienta

Herramientas aprobadas actuales (ejemplo — personaliza para tu organización):

2.2 Solicitud de Nuevas Herramientas

Cualquier empleado puede solicitar la evaluación de una nueva herramienta de IA enviando una solicitud al Comité de Gobernanza de IA. La solicitud debe incluir:

1. Nombre de la herramienta y proveedor
2. Caso de uso previsto y justificación de negocio
3. Tipos de datos que se procesarían
4. Número de empleados que la usarían

El comité evalúa las solicitudes dentro de 15 días hábiles usando los siguientes criterios:

• Prácticas de procesamiento y almacenamiento de datos (dónde se almacenan los datos, si se usan para entrenamiento, período de retención)
• Certificaciones de seguridad del proveedor (SOC 2, ISO 27001, disponibilidad de BAA HIPAA)
• Protecciones contractuales de datos
• Implicaciones de cumplimiento regulatorio
• Si una herramienta aprobada existente puede servir el mismo propósito

Las solicitudes son aprobadas, aprobadas con restricciones, o denegadas con explicación.

---

Sección 3: Clasificación de Datos para Uso de IA

Esta es la sección más importante de la política. La clasificación específica de datos elimina la ambigüedad que impulsa el uso de shadow AI.

3.1 Tabla de Clasificación de Datos

3.2 En Caso de Duda

Si un empleado no está seguro de qué nivel aplica a datos específicos, la regla es: trátalo como el nivel más alto y busca aclaración. Contacta a tu gerente o al Comité de Gobernanza de IA. Esto no es un castigo — es el comportamiento esperado cuando la clasificación es ambigua.

3.3 Datos de Nivel Mixto

Los prompts que contienen datos de múltiples niveles se rigen por el nivel más restrictivo. Una pregunta de investigación de Nivel 3 que incluye un nombre de cliente de Nivel 1 se convierte en un prompt de Nivel 1. Los empleados deben eliminar datos de nivel superior de los prompts cuando sea posible.

---

Sección 4: Guías de Uso Aceptable

4.1 Requisitos Generales

Todo uso de herramientas de IA debe:

• Usar cuentas corporativas, nunca cuentas personales
• Cumplir con la clasificación de datos de la Sección 3
• Producir salidas que sean revisadas por un humano antes de usarse en cualquier decisión, comunicación o entregable
• No ser representado como trabajo humano cuando la distinción importa (por ejemplo, presentaciones regulatorias, declaraciones juradas)

4.2 Usos Prohibidos

Independientemente del nivel de datos, los siguientes usos están prohibidos:

• Enviar credenciales, claves API o tokens de autenticación a cualquier herramienta de IA
• Usar herramientas de IA para tomar decisiones automatizadas sobre individuos (contratación, despido, préstamos, decisiones clínicas) sin revisión humana
• Usar salidas de IA en presentaciones regulatorias sin revisión y aprobación de un experto humano
• Evadir restricciones de herramientas de IA (VPNs para evitar bloqueos, dispositivos personales para evitar monitoreo)
• Usar herramientas de IA para generar contenido que viole cualquier ley o regulación

4.3 Guías Específicas por Departamento

Cada departamento debería mantener guías suplementarias que proporcionen ejemplos concretos relevantes a su trabajo. Ejemplos:

Ingeniería: El código generado por asistentes de IA debe pasar el mismo proceso de revisión que el código escrito por humanos. No pegues algoritmos propietarios ni esquemas de base de datos en herramientas externas. Usa la plataforma de IA interna para depurar código propietario.

Legal: Nunca pegues comunicaciones de clientes, estrategia de caso o materiales privilegiados en herramientas de IA externas. Los documentos borrador generados con asistencia de IA deben ser revisados por un abogado licenciado. La investigación legal generada por IA debe verificarse contra fuentes primarias.

Recursos Humanos: Nunca ingreses PII de empleados (nombres + compensación, nombres + calificaciones de desempeño, nombres + registros disciplinarios) en herramientas externas. Anonimiza los datos antes de usar IA para análisis.

Finanzas: Nunca ingreses resultados financieros no publicados, objetivos de M&A o información material no pública en ninguna herramienta de IA. Usa la plataforma de IA interna para modelado y análisis financiero.

---

Sección 5: Monitoreo y Aplicación

5.1 Alcance del Monitoreo

La organización monitorea el uso de herramientas de IA para proteger los datos de la empresa y asegurar el cumplimiento de la política. El monitoreo incluye:

• Tráfico de red a dominios conocidos de herramientas de IA
• Volumen de datos transmitidos a servicios de IA
• Escaneo automatizado de prompts salientes para patrones de datos de Nivel 1 (PII, PHI, credenciales)
• Patrones de uso y detección de anomalías

El monitoreo no incluye leer el contenido de cada prompt. Los sistemas automatizados señalan posibles violaciones de política, que luego son revisadas por el equipo de seguridad.

5.2 Framework de Aplicación

5.3 Provisión de Puerto Seguro

Los empleados que auto-reporten violaciones accidentales de política dentro de 24 horas no enfrentarán acción disciplinaria por violaciones de Nivel 2 de primera vez. Esta provisión existe para fomentar la transparencia. No aplica a violaciones de Nivel 1 que involucren PHI, PII o datos regulados donde existen obligaciones de reporte obligatorio.

---

Sección 6: Respuesta a Incidentes por Filtración de Datos

6.1 Cuando Se Detecta una Violación

1. Contener (dentro de 1 hora): Revocar el acceso del empleado a la herramienta de IA. Si la herramienta lo permite, solicitar la eliminación de los datos enviados.
2. Evaluar (dentro de 24 horas): Determinar qué datos fueron expuestos, su nivel de clasificación, si involucra datos regulados (PII, PHI, datos financieros) y el número de individuos afectados.
3. Notificar (según requisitos regulatorios): Si la exposición involucra datos regulados, iniciar el proceso de notificación apropiado:
   • HIPAA: Notificar al Oficial de Privacidad inmediatamente. El reloj de 60 días para notificación de brecha puede iniciar.
   • GDPR: Notificación de 72 horas a la autoridad supervisora si están involucrados datos personales de residentes de la UE.
   • Leyes estatales de notificación de brechas: Varía por jurisdicción. Consultar a legal.
   • SEC: Si está involucrada información material no pública, consultar a legal inmediatamente.
4. Remediar (dentro de 7 días): Contactar al proveedor de IA para solicitar eliminación de datos. Documentar la respuesta del proveedor. Si la ingestión de datos de entrenamiento es posible, documentar esto como una exposición irrecuperable.
5. Revisar (dentro de 30 días): Realizar un análisis de causa raíz. ¿La política era poco clara? ¿El empleado desconocía la clasificación? ¿No había alternativa aprobada para su caso de uso? Actualizar política y herramientas basándose en los hallazgos.

6.2 Documentación

Todos los incidentes deben documentarse en el Log de Incidentes de IA, incluyendo: fecha, empleado (anonimizado en reportes agregados), clasificación de datos, herramienta de IA involucrada, datos expuestos, acciones de contención, notificaciones regulatorias, causa raíz y pasos de remediación.

---

Sección 7: Requisitos de Capacitación

7.1 Capacitación Obligatoria

7.2 Contenido de la Capacitación

La capacitación debe incluir:

• Por qué existe la política (no solo reglas, sino razonamiento)
• Cómo acceder a herramientas de IA aprobadas
• Cómo clasificar datos antes de usar herramientas de IA
• Ejemplos reales de violaciones de política y sus consecuencias
• Cómo reportar violaciones accidentales (enfatizando puerto seguro)
• Cómo solicitar nuevas herramientas o capacidades

La capacitación que consiste únicamente en "esto es lo que no puedes hacer" es contraproducente. Empieza con "esto es lo que puedes hacer y cómo hacerlo de forma segura."

---

Sección 8: Calendario de Revisión

---

Overlay Regulatorio: HIPAA

Las organizaciones sujetas a HIPAA deben agregar las siguientes provisiones:

• PHI siempre es Nivel 1. Ninguna PHI puede ingresarse en ninguna herramienta de IA externa, incluso aquellas con Business Associate Agreements, a menos que el BAA cubra explícitamente el procesamiento asistido por IA y la herramienta haya sido específicamente aprobada para casos de uso con PHI.
• Estándar de desidentificación. Los datos desidentificados según el método Safe Harbor de HIPAA (18 identificadores eliminados) pueden tratarse como Nivel 2. Los datos desidentificados por el método de determinación de experto pueden tratarse como Nivel 3.
• Requisitos de BAA para proveedores de IA. Cualquier herramienta de IA aprobada para datos de Nivel 2 que pueda procesar PHI incidentalmente debe tener un BAA que aborde: uso de datos para entrenamiento de modelos (debe estar prohibido), retención y eliminación de datos, cronograma de notificación de brechas, derechos de auditoría y obligaciones de subcontratistas.
• Estándar de mínimo necesario. Los prompts que involucren cualquier dato relacionado con salud deben contener solo la información mínima necesaria para el propósito previsto.

Overlay Regulatorio: GDPR

Las organizaciones que procesan datos personales de residentes de la UE/EEE deben agregar:

• Base legal para procesamiento. El uso de herramientas de IA que involucre datos personales requiere una base legal identificada bajo el Artículo 6. Las evaluaciones de interés legítimo deben documentarse para casos de uso de IA.
• Mecanismos de transferencia de datos. Las herramientas de IA externas operadas por empresas estadounidenses requieren mecanismos de transferencia válidos (Cláusulas Contractuales Estándar, certificación del EU-US Data Privacy Framework o Reglas Corporativas Vinculantes).
• Requisito de DPIA. Debe completarse una Evaluación de Impacto en Protección de Datos antes de desplegar cualquier herramienta de IA que procese datos personales a escala, involucre toma de decisiones automatizada o procese categorías especiales de datos.
• Derecho a explicación. Cuando las salidas de IA influyen en decisiones sobre individuos, la organización debe poder explicar la lógica involucrada. Esto requiere mantener registros del uso de herramientas de IA en procesos de decisión.
• Derechos de los sujetos de datos. Los empleados, clientes y otros sujetos de datos retienen sus derechos (acceso, rectificación, supresión, portabilidad) para datos procesados a través de herramientas de IA.

Overlay Regulatorio: SOC 2

Las organizaciones que mantienen cumplimiento SOC 2 deben asegurar:

• Gestión de cambios. La introducción de nuevas herramientas de IA debe pasar por el proceso de gestión de cambios documentado en tus controles SOC 2.
• Control de acceso. El acceso a herramientas de IA debe aprovisionarse y desaprovisionarse a través de los mismos sistemas de gestión de identidad que otras aplicaciones. El uso de cuentas personales viola los requisitos de control de acceso.
• Logging y monitoreo. Los logs de uso de herramientas de IA deben retenerse por el mismo período que otros logs de acceso al sistema (típicamente 12 meses mínimo).
• Gestión de riesgo de proveedores. Los proveedores de IA deben evaluarse a través de tu programa de gestión de riesgo de proveedores. Las evaluaciones de riesgo deben documentarse y revisarse anualmente.
• Gestión de incidentes. Los incidentes de filtración de datos de IA deben gestionarse a través del proceso existente de gestión de incidentes y documentarse en consecuencia.

Overlay Regulatorio: EU AI Act

Las organizaciones que despliegan sistemas de IA en la UE deben considerar:

• Clasificación de riesgo. Determina si tus casos de uso de IA caen bajo las categorías prohibida, alto riesgo, riesgo limitado o riesgo mínimo bajo el EU AI Act.
• Obligaciones de alto riesgo. Si algún uso de IA califica como alto riesgo (por ejemplo, IA usada en decisiones de empleo, evaluación de solvencia o salud), aplican requisitos adicionales: sistemas de gestión de riesgos, gobernanza de datos, documentación técnica, supervisión humana y requisitos de precisión/robustez.
• Obligaciones de transparencia. Los usuarios deben ser informados cuando están interactuando con un sistema de IA. El contenido generado por IA debe etiquetarse como tal cuando podría confundirse con contenido generado por humanos.
• Modelos de IA de propósito general. Si se usan modelos base (GPT-4, Claude, Llama, etc.), asegurar cumplimiento con los requisitos de transparencia y documentación para modelos de IA de propósito general bajo el Artículo 53.

---

Ejemplo Aplicado: Política de Organización de Salud

Un sistema hospitalario de 500 camas con 4,000 empleados adaptó esta plantilla de la siguiente manera:

Herramientas aprobadas: Plataforma de IA interna (construida sobre Llama 3.3, desplegada on-premise) para todos los niveles. Microsoft Copilot para Microsoft 365 (licencia corporativa, solo Nivel 2 y 3, con PHI explícitamente prohibida). Sin herramientas de IA de consumo externas aprobadas.

Modificaciones clave: Agregó una prohibición específica de ingresar identificadores de pacientes (nombre, MRN, fecha de nacimiento) en cualquier prompt, incluso en la plataforma interna, a menos que el caso de uso haya sido aprobado por el Oficial de Privacidad. Creó una sub-política de "IA clínica" para herramientas de soporte de decisiones clínicas asistidas por IA, separada de la política general de IA. Requirió que el Comité de Gobernanza de IA incluya al Director de Informática Médica y un representante del personal clínico.

Resultado de aplicación: El uso de shadow AI bajó de un estimado del 45% del personal clínico al 8% dentro de 120 días del despliegue de la plataforma interna de IA y la política. El 8% restante fue principalmente médicos usando herramientas de IA médica especializadas que están siendo evaluadas para la lista aprobada.

Ejemplo Aplicado: Política de Firma de Servicios Financieros

Una firma de asesoría de inversiones de tamaño medio (800 empleados, registrada en SEC) adaptó esta plantilla:

Herramientas aprobadas: Plataforma de IA interna (on-premise, aislada de internet) para todos los niveles. Funcionalidades de IA del Terminal Bloomberg para datos de mercado de Nivel 2 y 3. Sin herramientas de IA de consumo externas aprobadas para ningún propósito.

Modificaciones clave: Agregó una prohibición explícita de ingresar información material no pública (MNPI) en cualquier herramienta de IA externa, con la violación tratada como un posible incidente de uso de información privilegiada que requiere revisión legal inmediata. Agregó un requisito de que la investigación de inversiones generada por IA lleve una etiqueta "asistida por IA" en todos los materiales dirigidos a clientes. Requirió preautorización para cualquier herramienta de IA usada en el desarrollo de estrategias de trading cuantitativo.

Resultado de aplicación: Consolidó todo el uso de IA en la plataforma interna dentro de 90 días. Dos incidentes en el primer trimestre: ambos violaciones de Nivel 2 (reportes internos ingresados en una extensión de navegador no aprobada con funcionalidades de IA), ambos detectados por monitoreo de endpoints, ambos resueltos mediante recapacitación.

---

La Paradoja de la Aplicación

La parte más difícil de la política de IA es calibrar la aplicación. La paradoja:

• Demasiado estricta: Los empleados perciben la política como irrazonable, el cumplimiento baja, el uso en la sombra aumenta, y la política existe solo en papel.
• Demasiado laxa: La política no proporciona protección significativa, los reguladores la ven como inadecuada, y ocurren incidentes sin un framework de respuesta.

El objetivo es un punto medio utilizable. La política debería ser lo suficientemente restrictiva para prevenir daño genuino y lo suficientemente permisiva para que los empleados puedan seguirla sin pérdida significativa de productividad.

La señal más fuerte de que tu política ha encontrado el balance correcto: los empleados reportan violaciones accidentales a través de la provisión de puerto seguro, solicitan nuevas herramientas a través del proceso formal, y el uso de la plataforma de IA interna crece mes a mes.

Si nadie está usando el puerto seguro, nadie está solicitando herramientas, y el uso de la plataforma interna es plano — tu política es demasiado estricta y los empleados la están evadiendo. Si estás viendo violaciones frecuentes de Nivel 1 — tu política es demasiado laxa o tu capacitación es inadecuada.

Mide, ajusta e itera. Una política es un documento vivo, no un monumento.