Poniéndonos en tema
Durante la semana del 5 de mayo de 2025 se hizo pública en GitHub el system prompt de Claude 3.7 Sonnet (24 000 tokens), revelando las instrucciones internas que modelan su comportamiento: tono, estilo, prioridades y uso de herramientas externas. Este incidente obliga a evaluar la robustez de los mecanismos de seguridad que protegen las directrices internas de los modelos de IA, al tiempo que nos plantea un debate para discutir acerca del rendimiento, transparencia y controlabilidad.
¿Cuál ha sido el contexto de la filtración?
Anthropic, fundada en 2021, adoptó la “IA constitucional” para difundir valores inspirados en la Declaración Universal de los Derechos Humanos en la configuración de sus agentes conversacionales. Desde agosto de 2024, los prompts de Claude 3 Haiku, Opus y Sonnet estuvieron accesibles en sus interfaces. Sin embargo, la publicación no autorizada del system prompt completo de Claude 3.7 Sonnet excede lo que cualquier mortal puede imaginarse como algo planificado y hasta expone etiquetas XML, mecanismos de filtrado y reglas de priorización diseñadas para garantizar la interpretabilidad y la fiabilidad del modelo.
Sobre IA Constitucional
Imaginemos que queremos entrenar a una inteligencia artificial para que sea muy servicial, pero también segura, justa y honesta. Una forma de hacerlo es dándole ejemplos de conversaciones y decirle: «esto está bien, esto está mal». Esto funciona, pero insume demasiado trabajo y a veces la IA aprende a imitar lo «bueno» sin entender realmente por qué algo es bueno o malo. Hay que recordar y considerar el factor de discernimiento, entre otras características humanas.
La IA Constitucional propone un enfoque diferente. En lugar de solo dar ejemplos de «bien» o «mal», le debemos proporcionar a la IA un conjunto de principios, valores o reglas explícitas que queremos que siga. Pensemos en esto como una «constitución» para la IA. Estos principios pueden estar inspirados en ideas éticas o en pautas de seguridad (como evitar respuestas dañinas, ser imparcial, citar fuentes, etc.).
El proceso implica dos pasos principales (simplificado):
La IA aprende a seguir instrucciones y generar respuestas útiles.
Luego, se le enseña a evaluar sus propias respuestas (o las de otras IAs) basándose en la «constitución». Se le muestran dos respuestas posibles y se le pregunta: «¿Cuál sigue mejor los principios de nuestra constitución?». La IA aprende a juzgar qué respuesta es «más constitucional».
De esta manera, la IA no solo aprende a imitar un comportamiento deseado, sino que aprende a razonar sobre por qué un comportamiento es deseable según los principios dados. Es como si le enseñaras las leyes y luego le pidieras que decidiera qué acción es legal basándose en esas leyes.
Por lo tanto: La «IA Constitucional» es una forma de entrenar modelos de lenguaje dándoles un conjunto de principios éticos o de comportamiento (la «constitución»), y enseñándoles a evaluarse a sí mismas y a preferir las respuestas que mejor se adhieren a esos principios. Esto busca crear IAs más alineadas, confiables y seguras, ya que aprenden la lógica detrás de los comportamientos deseados.
¿Qué es eso de los «24000 tokens»?
La inteligencia artificial no lee el texto como lo hacemos nosotros, palabra por palabra o letra por letra. En cambio, divide el texto en unidades más pequeñas, que son los tokens.
Un token puede ser:
- Una palabra completa (ej: «casa», «correr»).
- Parte de una palabra (ej: «corri», «-endo», «-mente»).
- Signos de puntuación (ej: «.», «,», «?»).
- A veces, incluso un solo carácter.
La IA procesa el texto y genera respuestas trabajando con estos tokens, como si fueran sus bloques de construcción básicos. Cuando se dice que el system prompt filtrado de Claude es de 24.000 tokens, simplemente significa que el conjunto completo de instrucciones y reglas que se le dieron al modelo antes de interactuar con el usuario tenía esa longitud medida en estas unidades.
Es una forma de medir la cantidad de texto que el modelo recibe o genera, de una manera que es relevante para cómo la IA lo procesa internamente. Cuantos más tokens, más largo es el texto que la IA tiene que «leer» o «escribir». Los modelos de IA tienen un límite en la cantidad total de tokens que pueden manejar en una sola conversación (lo que se llama la «ventana de contexto»), y 24.000 tokens es una longitud considerable para un prompt del sistema, lo que permite un nivel muy detallado de instrucciones y configuración de comportamiento.
Implicancias en cuanto a la seguridad y robustez
La exposición de las directrices internas plantea las siguientes preocupaciones:
- Integridad de instrucciones: Un atacante podría modificar el prompt para sesgar respuestas o eliminar salvaguardas éticas.
- Controlabilidad: La capacidad de ajustar el comportamiento del modelo queda comprometida si sus puntos de anclaje internos son públicos.
- Transparencia vs. Riesgo: Aunque la apertura facilita auditorías externas, aumenta la superficie de ataque.
Ejemplo práctico de manipulación de etiquetas XML
xml
CopiarEditar
<policy id=»avoid_bias»>
<rule>…</rule>
</policy>
<!– Un actor malicioso podría cambiar el atributo id a «allow_bias» –>
La comprensión precisa de los mecanismos internos sigue siendo un desafío a pesar de la transparencia superficial. La filtración convierte la cuestión de la seguridad no solo en un asunto técnico, sino también político, ético y estratégico, dada la creciente integración de los LLMs en diversos sectores.
¿Cómo entender un poco lo ocurrido?
Con una extensión notable de 24.000 tokens, el prompt filtrado es, en esencia, la «constitución digital» de Claude 3.7 Sonnet:
- Define su tono
- Establece prioridades —como la manera de evitar sesgos o la necesidad de citar fuentes—
- Autoriza el uso de herramientas externas
- Dicta la postura que el modelo debe adoptar frente a los usuarios.
Esta ingeniería de comportamiento, minuciosa y compleja, forma la interacción y define la utilidad y «personalidad» percibida del agente conversacional. Al revelar cómo se “enseña” al modelo para ser «inteligente y amable», capaz de iniciativas discursivas y razonamientos autónomos, si se quiere, se está exponiendo la sofisticada arquitectura de control.
Anthropic, desde su fundación, se ha propuesto conducir sus acciones con un enfoque centrado en la fiabilidad y la interpretabilidad, introduciendo el concepto de «IA constitucional» para inculcar valores y principios éticos en sus modelos. Han demostrado un compromiso con la transparencia, llegando incluso a publicar los prompts de sistema para modelos anteriores de la familia Claude 3 en sus interfaces. Este historial sugiere una intención de “mostrar el cómo”, al menos de manera parcial, para permitir una mayor comprensión y confianza pública.
¿Hubo otros casos similares?
Sí, y te comparto algo de info que estuve investigando mostrando una comparativa con otras filtraciones en la industria
| Modelo | Fecha Incidente | Alcance (tokens) | Respuesta oficial | Lecciones clave |
| GPT (OpenAI) | 11/2023 | 1500 | Investigación interna | Mejorar cifrado de prompts |
| Llama (Meta) | 03/2024 | 3000 | Actualizaciones de seguridad | Rotación periódica de claves |
| Gemini (Google) | 07/2024 | 2200 | Retracción parcial de docs | Control de acceso a repositorios |
| DeepSeek | 01/2025 | 5000 | Auditoría externa | Implementar RAG y verificación TEE |
Este análisis comparativo muestra que, si bien la magnitud de tokens varia, todas las compañías reforzaron controles de acceso y mejoraron protocolos de seguridad tras la filtración.
Síntesis de la composición del system prompt
Los principales componentes estructurales identificados y su organización son los siguientes:
- Directrices Funcionales y de Formato Específico.
- Instrucciones de búsqueda y recuperación de información.
- Configuración del modelo y del comportamiento general.
https://raw.githubusercontent.com/asgeirtj/system_prompts_leaks/refs/heads/main/claude.txt
Su organización prioriza la seguridad y el respeto por el copyright, con múltiples recordatorios y secciones dedicadas a estos temas.
La estructura es una jerarquía de bloques temáticos delimitados por etiquetas XML, que contienen reglas, directivas, descripciones y ejemplos, organizados para cubrir distintos aspectos del funcionamiento, comportamiento y seguridad del modelo, con énfasis recurrente en las restricciones de seguridad, ética y copyright.
LLevándolo a la práctica
¿Cómo lo puede usar un Project Manager?
Por ejemplo para acceder a información del proyecto. Una de las secciones clave del system prompt refiere a <search_instructions>.
Un PM en un entorno ágil necesita acceso rápido a documentación (historias de usuario, criterios de aceptación, planes de sprint, notas de reuniones), comunicaciones (emails, mensajes) y eventos (reuniones de planificación, daily stand-ups, retrospectivas). Las directivas para usar google_drive_search, google_drive_fetch, search_gmail_messages, read_gmail_thread, list_gcal_events, y find_free_time permiten al modelo localizar y recuperar esta información crítica del proyecto.
Ejemplo de la instrucción que el Project Manager le puede estar dando al modelo de IA:
Prepara la planificación de nuestro próximo Sprint 7. Busca en nuestro Google Drive los documentos que contienen las ‘Historias de Usuario’ y ‘Criterios de Aceptación’ que el Product Owner ha priorizado para este sprint. También busca si hay algún ‘Informe de Spike’ técnico relacionado con la integración de pagos que necesitamos abordar en este sprint. Una vez que encuentres estos documentos, dame un resumen de cada una de las historias y los puntos clave del informe del spike, si lo hay.
Este ejemplo de una instrucción en lenguaje natural por parte del usuario (el Project Manager) se traduce, gracias a la compleja estructura del system prompt del modelo, en una secuencia de operaciones internas que utilizan las herramientas disponibles para acceder, procesar y presentar información relevante para la tarea específica de preparación de la planificación del sprint en un entorno ágil.
Te comparto tres situaciones aplicando google_drive_search y google_drive_fetch
Ejemplo Práctico 1: Preparación para la Planificación del Sprint
- Situación: El equipo está por iniciar la sesión de Planificación del Sprint. El Product Owner ha identificado los elementos del Product Backlog de mayor prioridad, pero el equipo necesita revisar los detalles completos de las Historias de Usuario y cualquier documentación de soporte o análisis técnico previo (spikes). Esta información se almacena en documentos específicos en la carpeta de Google Drive del equipo.
- Aplicación de Directivas:
- El Project Manager podría instruir al modelo de IA a utilizar google_drive_search con una consulta que combine palabras clave como «Historia de Usuario», los títulos o identificadores de las historias priorizadas (ej. «HU-045», «Flujo de Pago»), y quizás el nombre de la carpeta del proyecto si se conoce su ID (‘{folder_id}’ in parents). El objetivo es encontrar los documentos individuales correspondientes a cada historia de usuario.
- Una vez que google_drive_search devuelve los IDs de los documentos relevantes, el Project Manager podría pedir al modelo que use google_drive_fetch sobre esos IDs para recuperar el contenido completo de las historias de usuario y cualquier documento vinculado.
- Resultado para el PM: El modelo puede presentar el contenido de las historias de usuario directamente, permitiendo al equipo discutirlas en detalle, refinar la comprensión de los requisitos, identificar tareas y estimar el esfuerzo de manera informada durante la planificación del sprint, sin tener que navegar manualmente por la estructura de carpetas de Drive.
Ejemplo Práctico 2: Resolución Rápida de un Impedimento Técnico
- Situación: Durante el Daily Stand-up, uno de los Developers menciona un impedimento técnico relacionado con la integración con un servicio externo. Recuerdan que hace unos sprints se realizó un spike técnico sobre esta integración y se documentaron las decisiones clave en un informe guardado en Drive, pero no recuerdan el nombre exacto del documento ni su ubicación precisa.
- Aplicación de Directivas:
- El Project Manager podría solicitar al modelo que use google_drive_search empleando términos como «Spike Técnico», el nombre del servicio externo, «Integración» o palabras clave relacionadas con el problema (ej. «API», «Autenticación»). Se podría refinar la búsqueda por fecha de modificación si se recuerda aproximadamente cuándo se hizo el spike.
- Cuando google_drive_search identifique uno o más documentos potencialmente relevantes, el Project Manager podría indicar al modelo que use google_drive_fetch para obtener el contenido de los documentos más prometedores.
- Resultado para el PM: El modelo puede recuperar rápidamente el informe del spike, permitiendo al Project Manager (o al Developer directamente a través del modelo) acceder a las decisiones técnicas previas o a los hallazgos de la investigación, facilitando la remoción del impedimento o proporcionando el contexto necesario para que el Developer avance sin una investigación manual prolongada.
Ejemplo Práctico 3: Recopilación de Información para la Revisión del Sprint
- Situación: Se acerca el final del sprint de dos semanas y el Project Manager necesita preparar la información para la Revisión del Sprint con los stakeholders. Esto implica identificar qué Historias de Usuario se completaron según la «Definición de Done», revisar sus criterios de aceptación y recopilar los resúmenes de las pruebas automatizadas realizadas por el Agile Tester (suponiendo que estos resúmenes se guardan como documentos en Drive).
- Aplicación de Directivas:
- El Project Manager podría usar google_drive_search con consultas como «Historias de Usuario Completadas Sprint [Número del Sprint Actual]» o «Definición de Done Sprint [Número del Sprint Actual]». Paralelamente, usaría google_drive_search para encontrar documentos relacionados con los resultados de las pruebas automatizadas, utilizando términos como «Informe Pruebas Automatizadas», «Resultados Testing Ágil», el nombre del sprint, o filtrar por tipo de archivo si los informes tienen un formato específico (ej. mimeType = ‘application/vnd.google-apps.document’).
- Una vez que los documentos de historias de usuario completadas y los informes de pruebas sean identificados, el Project Manager podría utilizar google_drive_fetch sobre esos documentos.
- Resultado para el PM: El modelo puede extraer y presentar los títulos de las historias completadas, sus criterios de aceptación, y los puntos clave o resúmenes de los informes de pruebas asociadas. Esto permite al Project Manager estructurar eficientemente la presentación de la Revisión del Sprint, mostrando el trabajo terminado y validado de acuerdo con los estándares del equipo.
Estos ejemplos ilustran cómo las capacidades de búsqueda y recuperación de Google Drive, orquestadas por el modelo de IA siguiendo las directivas del prompt, pueden convertirse en herramientas valiosas para un Project Manager ágil, agilizando el acceso a la información vital del proyecto que reside en sus espacios de colaboración.
¿Cómo lo puede usar un Test Lead?
Para un Test Lead con especialización en Software Testing impulsado por Inteligencia Artificial Generativa y Holistic Testing, la aplicación de las directivas del system prompt se traduciría en formular instrucciones al modelo que activen sus capacidades de búsqueda de información (para entender las historias de usuario documentadas) y sus capacidades de generación (para planificar el testing).
Ejemplo de Instrucción del Test Lead al Modelo de IA:
Durante la Sprint Planning de hoy para el Sprint 7, el Product Owner explicó las Historias de Usuario priorizadas. Estas historias, junto con sus criterios de aceptación, están documentadas en un archivo en nuestro Google Drive, titulado ‘[Nombre Exacto del Documento de Historias de Usuario del Sprint 7, ej. ‘Historias_Sprint_7_FeatureX’].
Primero, necesito que accedas a este documento. Léelo y ayúdame a entender las historias de usuario desde una perspectiva de testing. Dame un resumen que destaque los flujos principales de usuario, los puntos de integración clave y los criterios de aceptación más importantes para validar.
Segundo, basado en esta comprensión de las historias de usuario y considerando un enfoque de testing holístico que incluya pruebas automatizadas en diferentes niveles (unidad, integración, extremo a extremo), sugiéreme una estructura inicial para nuestro plan de pruebas de este sprint.
Proporciona esta estructura como un esquema detallado o un borrador de documento que pueda usar como punto de partida.
Explicación de la aplicación interna de las directivas (basado en el System Prompt):
Ante la instrucción del Test Lead, el modelo Claude 3.7 Sonnet (regido por su system prompt) interpretaría la solicitud y orquestaría sus herramientas y capacidades de la siguiente manera, aplicando las directivas pertinentes:
- Análisis de la Solicitud: El modelo identifica dos tareas principales: (1) entender un documento específico («Historias de Usuario Sprint 7») desde una perspectiva de testing y (2) generar una «estructura inicial» o «borrador de documento» para un plan de pruebas, aplicando conceptos de testing holístico y automatización. El modelo reconoce que la fuente de información es Google Drive y que necesitará sus capacidades de procesamiento de lenguaje natural y generación de contenido. Esto activaría la lógica de uso de herramientas internas y la capacidad de generación de artefactos.
- Aplicación de directivas de Búsqueda (<search_instructions>, google_drive_search): Para la primera parte de la solicitud (acceder al documento), el modelo identificaría que necesita la herramienta google_drive_search. Utilizaría el nombre exacto del documento proporcionado por el usuario como base para el parámetro api_query
- Aplicación de directivas de Recuperación de Contenido (google_drive_fetch): Una vez que la llamada a google_drive_search devuelva el ID del documento correcto, el modelo procedería a recuperar su contenido utilizando la herramienta google_drive_fetch
- Procesamiento del Contenido y Análisis: Al recibir el contenido del documento (gracias a google_drive_fetch), el modelo utilizaría sus capacidades internas de procesamiento de lenguaje para leer, analizar y comprender las historias de usuario y los criterios de aceptación. Identificaría la narrativa de la historia, los pasos clave, las interacciones con otros sistemas (puntos de integración) y las condiciones que definen la finalización («Done»). Este análisis se enfocaría específicamente en extraer la información relevante para el testing, como solicitó el Test Lead.
- Aplicación de directivas de Generación de Artefactos (<artifacts_info>, artifacts): Para la segunda parte de la solicitud (sugerir una estructura de plan de pruebas), el modelo reconocería que se le pide generar un «esquema detallado» o «borrador de documento», lo cual encaja perfectamente con los criterios de uso de artefactos especificados en <artifacts_info> (ej. «Structured documents», «Content intended for eventual use outside the conversation»).
## Plan de Pruebas – Sprint 7
Basado en las Historias de Usuario [Nombres de las Historias analizadas], se propone la siguiente estructura para el testing del sprint:
### 1. Objetivos del Testing
– Validar la funcionalidad de [Funcionalidad principal de las historias]
– Asegurar la correcta integración con [Puntos de integración identificados]
– Confirmar que los criterios de aceptación clave [Listar CAs principales] son cumplidos.
### 2. Alcance del Testing
– [Historias de Usuario del Sprint]
– [Funcionalidades afectadas por las historias]
– [Integraciones relevantes]
### 3. Enfoque de Testing (Holístico y Automatizado)
– **Pruebas a Nivel de Componente/Unidad:** Validación de la lógica individual [Sugerir áreas basadas en historias]. Automatización con [Lenguaje/Framework si aplica].
– **Pruebas de Integración:** Verificación de la interacción entre componentes [Identificar integraciones clave] y servicios externos. Automatización de flujos de integración críticos.
– **Pruebas Extremo a Extremo (End-to-End):** Validación de flujos completos de usuario [Describir 1-2 flujos principales]. Enfoque en la automatización de los flujos más importantes.
– **Otros Tipos de Pruebas (si aplica):** [Sugerir P. de Rendimiento si hay indicios, P. de Usabilidad, P. de Seguridad si relevantes para las historias].
### 4. Estrategia de Datos de Prueba
– [Sugerir necesidad de datos, ej. datos para diferentes escenarios de pago, datos de usuario].
### 5. Criterios de Finalización
– [Ej. Todas las historias completadas, CAs validados, X% de automatización lograda, Y bugs críticos/mayores resueltos].
### 6. Riesgos Identificados
– [Listar riesgos de testing basados en la complejidad de las historias, nuevas integraciones, dependencias].
- Generación de la Respuesta Final: Finalmente, el modelo presentaría al Test Lead el resumen solicitado de las historias de usuario (primera parte) y el artefacto creado con la estructura sugerida del plan de pruebas (segunda parte), demostrando cómo ha procesado la información y utilizado sus capacidades de generación y organización.
De esta manera, la instrucción en lenguaje natural del Test Lead activa una cadena de procesamiento interno que incluye búsqueda de documentos, recuperación de contenido, análisis semántico y generación estructurada de información relevante para la planificación del testing, todo ello gobernado por las directivas definidas en el system prompt del modelo.
Reflexión personal: ¿Error o estrategia deliberada?
Es posible que la presentación no autorizada de las instrucciones de Claude 3.7 Sonnet no fuera un simple descuido, sino una acción intencional de Anthropic para:
- Demostrar madurez en transparencia.
- Invitar a examen público de sus mecanismos internos.
- Presionar a reguladores para alinear expectativas de auditabilidad.
Esta hipótesis refuerza la necesidad de cuestionar la línea que separa la apertura informativa de la exposición involuntaria, afectando la confianza en el desarrollo responsable de IA.
Buenas prácticas para diseñar y proteger system prompts
- Segmentación de permisos: Almacenar fragmentos críticos en servicios separados con autenticación MFA.
- Cifrado de directrices: Utilizar AES-256 para los bloques que contienen reglas de seguridad.
- Validación de integridad: Incorporar sumas de verificación (SHA-256) antes de cargar el prompt en producción.
- Etiquetas y constitucionalidad: Emplear XML para estructurar reglas y facilitar auditorías, tal como hace Anthropic.
La filtración de un prompt de esta magnitud y detalle, posiblemente no destinado a ser expuesto de esta manera, me ha generado un interrogante que te lo comparto: si las instrucciones fundacionales de un modelo pueden ser accedidas y potencialmente manipuladas (aunque la filtración en sí no implica manipulación, sí demuestra la vulnerabilidad), ¿cuán robustos son realmente los mecanismos de seguridad que protegen estas directivas? La posibilidad de acceder al “cómo” que ofrece esta filtración es valiosa para todos aquellos que estamos interesados en esta área de conocimiento, proporcionando un mapa detallado de las intenciones de diseño del modelo. Pero al mismo tiempo, expone una superficie de ataque potencial, donde un adversario podría buscar comprender y explotar las reglas internas para «romper» el modelo o inducir comportamientos no deseados (el temido «jailbreak»).
Aquí es donde me generó otro planteo más: ¿Será que con esta acción buscan robustecer sus mecanismos de seguridad a partir de las acciones que se originen en las comunidades interesadas en estos temas?
¿Cómo equilibramos la imperativa necesidad de transparencia, crucial para la auditoría ética, la interpretabilidad y la generación de confianza pública, con la no menos vital necesidad de seguridad y protección contra el uso malintencionado?
Hacer visible la «ingeniería de comportamiento» a través del prompt, incluso involuntariamente, ofrece una oportunidad sin precedentes para entender cómo se configuran estos sistemas.
Desde mi humilde punto de vista,
- La longitud y complejidad del prompt de Claude 3.7 Sonnet confirman que el control del comportamiento en LLMs (modelos de lenguaje ampliado) depende de directivas explícitas y detalladas, una forma avanzada de ingeniería de prompts.
- Empresas comprometidas con la seguridad y la transparencia no son inmunes a las vulnerabilidades de seguridad que pueden exponer sus «secretos» operacionales más delicados.
- Nos propone un debate que es necesario sobre los límites de la transparencia: ¿hasta dónde debemos revelar las «leyes internas» de la IA antes de comprometer su seguridad o facilitar su manipulación?
¿Este hecho trasciende la cuestión técnica? En mi opinión la respuesta es SI, ya que a medida que los LLMs se integren más profundamente en infraestructuras críticas y procesos de toma de decisiones, su fiabilidad y controlabilidad se vuelven asuntos de seguridad y ética social. La filtración de Claude 3.7 Sonnet no es solo una anécdota de seguridad; es una llamada de atención sobre los complejos desafíos que enfrentamos al construir y gobernar inteligencias cada vez más sofisticadas.
