Cuando una organización detecta un uso indebido de inteligencia artificial, suspender el acceso parece una respuesta inmediata y lógica. Pero surge una pregunta más difícil: ¿qué ocurre con el software, los procesos y las capacidades que ya se construyeron?
Qué documentó Anthropic y qué no conviene asumir
En su informe de amenazas de septiembre de 2026, Anthropic describe usos indebidos relacionados con vigilancia, influencia y armamento. Son casos seleccionados, no una medición de su prevalencia.
La compañía atribuye a un consultor el uso de Claude para desarrollar Lakana 360, una plataforma de vigilancia para inteligencia estatal. El número de tarjetas SIM mencionado en el informe no equivale a personas únicas. La plataforma operaba localmente: bloquear la cuenta interrumpió la asistencia al desarrollo, pero no desactivó lo desplegado.
El documento también describe desarrollo de software para drones militares por actores vinculados con Rusia. La validación en simulación no demuestra un despliegue en combate ni equivale a que Claude decidiera ejecutar operaciones militares por iniciativa propia.
El riesgo también vive fuera del modelo
Una evaluación centrada únicamente en las respuestas del chatbot deja preguntas importantes sin resolver: ¿quién puede convertir una respuesta en código operativo?, ¿qué datos alimentarán ese sistema?, ¿quién autoriza su conexión con infraestructura real?, ¿qué sucede si cambia el propósito original del proyecto?
La revisión de seguridad debería acompañar el recorrido completo: solicitud, generación, validación, integración, despliegue y operación. No basta con aprobar una herramienta; también es necesario definir para qué puede utilizarse y bajo qué condiciones.
La finalidad importa tanto como la capacidad técnica
Una misma función puede tener usos muy distintos. Clasificar documentos para facilitar una auditoría no plantea las mismas preguntas que clasificar personas para someterlas a vigilancia. Generar mensajes para atención al cliente tampoco equivale a producir contenido destinado a manipular audiencias de manera encubierta.
La gobernanza debe examinar el propósito, la autorización y los posibles efectos sobre terceros, además de la calidad técnica. Cuando intervienen datos personales, perfiles o identificadores biométricos, la revisión requiere participación de privacidad y cumplimiento.
Supervisar no es aprobar al final
La supervisión humana pierde valor si se limita a firmar una autorización cuando el sistema ya está terminado. Debe existir desde la definición del objetivo y mantenerse cuando aumenta el impacto: acceso a nuevos datos, incorporación de herramientas, ampliación de permisos o paso a producción.
Los responsables de aprobar necesitan evidencia comprensible: qué hará el sistema, qué no podrá hacer, cuáles son sus dependencias y cómo se detectarán desviaciones. También deben tener autoridad real para detenerlo.
La respuesta debe alcanzar los sistemas derivados
Revocar una cuenta, una sesión o una clave puede cerrar una vía de acceso. Sin embargo, no retira automáticamente un programa ya distribuido ni elimina sus copias. Una organización preparada debería poder identificar qué aplicaciones se desarrollaron con asistencia de IA, quién es responsable de ellas y dónde están desplegadas.
Ante un incidente, esa información permite decidir si corresponde aislar servicios, suspender integraciones, revisar permisos o retirar una versión. Las acciones deben responder al riesgo observado y preservar la evidencia necesaria para investigar.
Del acceso al modelo al control de la arquitectura
Conviene distinguir tres capas de control: el servicio de IA —cuentas, condiciones y límites—; la aplicación que integra el modelo —instrucciones, conectores, permisos y lógica—; y el entorno donde se ejecutan las acciones —bases de datos, repositorios, servicios e infraestructura—.
Un control aplicado en la primera capa no se transmite automáticamente a las otras dos. Un proveedor puede suspender una cuenta mientras una aplicación ya creada continúa operando con componentes locales. Las acciones sensibles deberían quedar sujetas a controles independientes del modelo.
Qué debería incluir una revisión antes de producción
- Definir un objetivo verificable y sus límites.
- Identificar dependencias, datos, permisos y puntos donde una salida del modelo se transforma en una acción real.
- Probar información incompleta, resultados contradictorios, solicitudes fuera de alcance y fallas de integración.
- Contar con una ruta de reversión y probarla antes de habilitar operaciones sensibles.
- Medir cuánto tarda el equipo en contener una acción no autorizada durante un ejercicio.
Innovar con límites verificables
El objetivo no debería ser elegir entre adoptar IA o controlar sus riesgos. La oportunidad está en diseñar una adopción con límites claros, responsabilidades asignadas y mecanismos de intervención que funcionen fuera del documento de políticas.
Para los líderes, una pregunta resume el desafío: si mañana detectamos que un proyecto está siendo utilizado de manera indebida, ¿podemos detener sus efectos o únicamente cancelar el acceso a la herramienta que ayudó a crearlo?
Fuente principal: Anthropic — Threat Intelligence Report, septiembre de 2026. Los hechos se atribuyen a la investigación de la compañía; las recomendaciones de gobernanza corresponden al análisis de este artículo.