¿Tu empresa usa Cursor, Codex o Copilot sin una política? Riesgos y controles mínimos
Cursor, Codex, Copilot y otras herramientas de programación con IA pueden entrar en la empresa antes de que TI, seguridad y legal hayan definido reglas claras. Un desarrollador los usa en el IDE, un equipo habilita el modo agente, un contratista pega registros (logs) en el chat, un departamento experimenta con repositorios de clientes. Todo parece productivo, pero nadie sabe realmente qué datos han salido, qué herramientas están autorizadas y qué modificaciones requieren revisión.
Una política de programación con IA no sirve para bloquear la innovación: sirve para hacer explícito quién puede usar qué herramientas, sobre qué datos, con qué permisos y con qué controles antes de la integración (merge) o el despliegue.
Para CISO, CTO, gerentes de TI y legal, el punto no es elegir un proveedor de una vez por todas. El punto es evitar que cada equipo invente su propia regla mientras el código, los prompts, los secretos y las responsabilidades se mueven fuera de control.
Por qué es necesaria una política incluso con herramientas empresariales
Las funciones empresariales ayudan: SSO, RBAC, exclusión de contenido, registros de auditoría (audit logs), entornos aislados (sandbox), políticas de aprobación, controles sobre agentes en la nube o locales. Pero estos ajustes gobiernan la herramienta, no garantizan automáticamente que el código producido sea seguro, que los datos sean lícitos de usar o que cada solicitud de extracción (pull request) tenga la revisión adecuada.
Una política corporativa debe unir tres niveles distintos. El primero se refiere a las herramientas: qué instrumentos están permitidos, con qué cuentas y configuraciones. El segundo se refiere a los datos: qué no puede ser insertado en prompts, contexto, registros o espacios de trabajo. El tercero se refiere al proceso: cuándo se necesitan revisiones, pruebas, puntos de control (gates), registro de actividades, formación y excepciones. Sin estos niveles, la empresa corre el riesgo de tener una falsa sensación de control: “tenemos Copilot Enterprise” o “Codex está en una sandbox” no responde a la pregunta sobre qué repositorios están permitidos, qué datos están prohibidos y quién aprueba una PR que modifica la autenticación, las canalizaciones (pipelines) o los secretos.
Definir herramientas permitidas y herramientas prohibidas
La política debe partir de un inventario que incluya Cursor, Codex, Copilot, Claude Code, extensiones de IDE, chats genéricos, complementos, servidores MCP, agentes en la nube, herramientas de código abierto, cuentas personales, planes gratuitos y entornos de prueba. Para cada herramienta se debe definir al menos el propietario interno, el plan permitido, los requisitos mínimos (SSO, MFA, registro, gestión de accesos, retención de datos, privacidad), los repositorios o equipos autorizados, las funcionalidades habilitadas y el proceso para solicitar excepciones.
La regla no debe ser “usa la IA con sentido común”. Debe decir qué está permitido, qué está prohibido y qué requiere aprobación.
Escribir la lista de datos prohibidos en los prompts
La parte más importante de la política suele ser la más concreta: qué no se puede pegar o poner a disposición del modelo. Algunos elementos deben prohibirse explícitamente o autorizarse solo con un proceso específico:
- Secretos, tokens, contraseñas, cookies, claves en la nube y claves API.
- Datos personales, datos de clientes, datos sanitarios, financieros o de RR. HH.
- Registros con PII, encabezados, seguimientos de pila (stack traces) o identificadores de clientes.
- Volcados de bases de datos y archivos de producción.
- Contratos, documentos confidenciales, informes de incidentes e informes de vulnerabilidad.
- Código de clientes o terceros no autorizado.
- Arquitecturas, puntos finales (endpoints) internos y configuraciones de producción no redactadas.
No basta con escribir “no insertar datos sensibles”. Se necesitan ejemplos cercanos al trabajo real de los desarrolladores: registros de error, archivos .env, tickets, capturas de pantalla, consultas, archivos de prueba, transcripciones, configuraciones en la nube.
Gobernar repositorios, contexto e indexación
Muchas herramientas de IA trabajan leyendo archivos abiertos, repositorios, espacios de trabajo, ramas (branches), incidencias, documentación o contexto indexado. Si la empresa no define límites, el agente puede ver mucho más de lo necesario. La política debe, por tanto, distinguir entre repositorios públicos, repositorios internos, código de cliente, monorepos, proyectos regulados, componentes con secretos, entornos de producción y repositorios heredados: algunos pueden permitirse con exclusiones, otros requieren solo modo de solo lectura o la prohibición de indexación.
Controles útiles en este ámbito:
- Archivos de exclusión para directorios sensibles.
- Lista blanca (allowlist) de repositorios autorizados.
- Prohibición en proyectos de clientes sin consentimiento contractual.
- Separación entre diferentes clientes.
- Escaneo de secretos antes del uso de agentes.
- Revisión de la configuración de indexación y retención.
Establecer cuándo están permitidos el modo agente, el terminal y los agentes en la nube
El autocompletado y el chat no tienen el mismo perfil de riesgo que un agente que modifica archivos, ejecuta comandos, abre solicitudes de extracción, usa servidores MCP o trabaja en la nube con una copia del repositorio. La política debe clasificar las modalidades operativas y asociar a cada una una regla mínima.
| Modalidad | Riesgo | Regla mínima |
|---|---|---|
| Chat o completado local | Uso indebido de datos y fragmentos | Datos prohibidos, revisión de código, cuenta corporativa |
| Modificación de archivos en el repositorio | Diferencias (diffs) vulnerables o demasiado amplias | PR obligatoria, revisor propietario, protección de rama |
| Terminal o comandos | Secretos, efectos secundarios, instalaciones | Sandbox, aprobación, no producción |
| Agente en la nube | Código y contexto en entorno remoto | Repositorios autorizados, red limitada, secretos separados |
| MCP/herramientas externas | Acciones en sistemas corporativos | Lista blanca de herramientas, menor privilegio, registro de auditoría |
Si una modalidad permite escritura, despliegue, acceso a la red o uso de herramientas externas, no debe estar habilitada por defecto en todos los repositorios.
Hacer obligatoria la revisión en áreas sensibles
La política debe aclarar que el código generado por la IA sigue siendo responsabilidad del equipo: una PR que pasa las pruebas no es automáticamente aceptable. La revisión se vuelve obligatoria cuando la modificación afecta a la autenticación, sesiones, restablecimiento de contraseñas, MFA o devoluciones de llamada OAuth; autorizaciones, roles, aislamiento de inquilinos (tenant isolation), middleware y políticas; API, consultas, serializadores, carga, exportación y pagos; secretos, variables de entorno, registros y manejo de errores; dependencias, archivos de bloqueo (lockfiles), gestores de paquetes y scripts de instalación; CI/CD, Dockerfile, IaC, nube, IAM y despliegue; prompts en tiempo de ejecución, llamadas a herramientas, RAG, memoria o agentes de aplicación.
La conexión con la Revisión de Código es directa: la política define cuándo es necesaria la revisión, mientras que la revisión verifica las diferencias y las posibles regresiones.
Registro, auditoría y evidencias
Una política sin evidencias es difícil de aplicar. La empresa debe saber qué herramientas están habilitadas, qué usuarios las utilizan, qué repositorios están involucrados, qué agentes pueden modificar código, qué excepciones han sido aprobadas y qué PR han sido generadas o asistidas por IA. No siempre es necesario registrar el contenido de los prompts, que puede ser sensible, pero sí se necesitan los datos de gobernanza: herramientas activas, usuarios, configuraciones, repositorios, aprobaciones, excepciones, hallazgos, revisiones y decisiones de integración.
Para la respuesta ante incidentes, las evidencias deben permitir responder a preguntas concretas: ¿qué agente produjo esta modificación? ¿Qué contexto podía leer? ¿Tuvo acceso a secretos? ¿Usó la red o herramientas externas? ¿Quién aprobó la PR?
Formación: ejemplos prácticos, no principios abstractos
La formación eficaz muestra casos reales del trabajo diario, no principios genéricos sobre la ética de la IA. Los desarrolladores necesitan saber qué hacer concretamente: un registro de producción que no debe pegarse en el chat, una clave API en un archivo de configuración que debe rotarse si ha entrado en el prompt, una PR generada por IA que modifica middleware y pruebas, una dependencia sugerida por la IA que debe verificarse antes de la integración, una política CORS o IAM ampliada para “hacer funcionar” la compilación, un archivo de cliente que no puede ser indexado. Estos ejemplos hacen que la política sea comprensible y aplicable, en lugar de ser un documento que nadie consulta.
Gestionar excepciones y despliegue
Cada política debe prever excepciones, de lo contrario, las excepciones se vuelven informales. Un equipo puede tener un caso experimental, una herramienta aún no aprobada, un repositorio piloto o una necesidad temporal: en todos estos casos, la excepción debe tener propietario, duración, perímetro, riesgo aceptado, controles compensatorios y revisión. Si permanece activa sin fecha de caducidad, ya no es una excepción, sino una segunda política no gobernada.
Para el despliegue, conviene empezar por repositorios piloto, medir los problemas, actualizar la política y luego extenderla. Una política mínima pero aplicada y mejorada con el tiempo funciona mejor que una política perfecta escrita antes de cualquier prueba.
Lista de verificación mínima para una política de programación con IA
- Inventario de las herramientas de programación con IA utilizadas por empleados y contratistas.
- Herramientas autorizadas, prohibidas y en fase piloto.
- Requisitos mínimos: SSO, MFA, registro, gestión de accesos, retención de datos.
- Datos prohibidos en los prompts y en el contexto, con ejemplos concretos.
- Repositorios permitidos, excluidos o sujetos a aprobación.
- Reglas para el modo agente, terminal, agentes en la nube, red y MCP.
- Escaneo de secretos y exclusión de archivos antes del uso en repositorios sensibles.
- Revisión obligatoria para áreas críticas del código.
- Puntos de control (gates) de CI/CD mínimos para PR generadas por IA.
- Registro y auditoría coherentes con la privacidad y la respuesta ante incidentes.
- Formación práctica para desarrolladores, revisores y gerentes.
- Proceso de excepción con propietario, fecha de caducidad y riesgo aceptado.
Cuándo involucrar a ISGroup
Si la empresa ya está usando programación con IA sin reglas claras, la prioridad es entender la exposición y el riesgo: herramientas activas, datos tratados, repositorios involucrados, controles de proveedores, políticas internas, canalizaciones y revisiones.
| Escenario | Riesgo principal | Servicio recomendado |
|---|---|---|
| Uso generalizado sin propiedad clara | Gobernanza débil y responsabilidades no asignadas | Virtual CISO |
| Adopción continua de programación con IA en los equipos | Controles no repetibles en PR, canalizaciones y lanzamientos | Software Assurance Lifecycle |
| Repositorios ya modificados por IA en áreas sensibles | Vulnerabilidades o regresiones en el código | Code Review |
| Aplicaciones web desarrolladas con programación con IA | Fallos de aplicación no detectados antes del despliegue | Web Application Penetration Testing |
El resultado esperado no es un documento largo que nadie lee, sino una política aplicable: pocas reglas claras, responsabilidades definidas, umbrales de escalada y controles técnicos conectados al proceso.
Preguntas frecuentes
- ¿Es necesario prohibir Cursor, Codex o Copilot en la empresa?
- No necesariamente. Por lo general, es más eficaz autorizar herramientas y casos de uso específicos, prohibir datos y repositorios sensibles, imponer revisiones en las áreas críticas y configurar los controles empresariales disponibles.
- ¿Son suficientes los ajustes empresariales del proveedor?
- No. Son necesarios, pero gobiernan la herramienta. La seguridad de la aplicación sigue dependiendo del código, los datos, los repositorios, las revisiones, las canalizaciones, las licencias, las dependencias y las responsabilidades internas.
- ¿Qué datos no deben entrar en los prompts?
- Secretos, tokens, contraseñas, datos personales, datos de clientes, registros con PII, volcados, contratos, informes de incidentes, informes de vulnerabilidad, código no autorizado y configuraciones de producción no redactadas.
- ¿Quién debe poseer la política de programación con IA?
- Se necesita propiedad compartida: CTO o ingeniería para el proceso técnico, CISO para el riesgo, TI para los accesos, legal y privacidad para datos y contratos, compras para proveedores y cláusulas.
- ¿Cuándo se necesita una Revisión de Código?
- Cuando una PR generada o asistida por IA afecta a la autenticación, roles, API, consultas, secretos, dependencias, canalizaciones, nube, pagos o lógica de negocio. La política debe hacerlo explícito antes de que la PR llegue a la integración.
[Callforaction-SAL-Footer]