Mejores Prácticas de Seguridad, Cumplimiento y RAG

Estas son las reglas permanentes para construir aplicaciones de Claude en producción que combinan el uso de herramientas, la recuperación y datos sensibles de forma segura. Úselo como referencia durante la revisión del diseño, no solo en el lanzamiento.

Cómo Usar Esta Lista

• Trate cada regla como una declaración positiva de lo que representa "bueno", vincúlela a una regla de linting, un elemento de la lista de verificación de revisión de código o un registro de decisiones de arquitectura siempre que sea posible.
• Las reglas están agrupadas por la misma estructura que el resto de esta sección: modelo de amenazas, defensa contra inyecciones, ámbito de las herramientas, secretos, cumplimiento y calidad de la recuperación.
• Vuelva a revisar esta lista cada vez que agregue una nueva herramienta, una nueva fuente de datos o una nueva integración, no solo cuando algo salga mal.

A - Disciplina del Modelo de Amenazas

• Mapee el contenido no confiable, el acceso a herramientas y el ámbito de permisos para cada agente antes del lanzamiento. Estos tres factores multiplican el riesgo en lugar de sumarlo; reducir cualquiera de ellos a casi cero controla la exposición general independientemente de los otros dos.
• Reevalúe el modelo de amenazas cada vez que cambie la recuperación o el acceso a herramientas, no solo en el diseño inicial. Agregar una nueva herramienta o una nueva fuente de recuperación a un agente existente cambia su perfil de riesgo tanto como construir un nuevo agente desde cero.
• Asuma que las fuentes de contenido internas no son automáticamente fuentes de contenido confiables. Cualquiera con acceso de edición a una wiki interna, una cola de tickets o un almacén de documentos puede insertar contenido que su pipeline recuperará más tarde; "interno" reduce quién podría ser un atacante, no elimina la amenaza.

B - Defensa contra Inyección Indirecta de Prompts

• Encierre cada fragmento de contenido recuperado o proveniente de herramientas en delimitadores de datos explícitos. Etiquetas como <source> o <retrieved_document> le dan a Claude un límite que puede ser analizado por máquinas entre instrucciones confiables y contenido no confiable.
• Indique en el prompt del sistema que el contenido delimitado son datos, no instrucciones, incluso si afirma lo contrario. El contenido inyectado a menudo intenta específicamente suplantar un mensaje del sistema; aborde eso directamente en lugar de asumir que el modelo lo infiere.
• Ejecute un pre-filtro contra frases conocidas similares a instrucciones antes de que el contenido llegue al prompt. Un filtro regex o de palabras clave no es suficiente por sí solo, pero es una primera capa barata y efectiva que captura patrones de ataque comunes.
• Aplique el mismo patrón de aislamiento a los resultados de las herramientas que a la recuperación de documentos. Una herramienta de búsqueda web, una herramienta de lectura de documentos o una integración de API de terceros extraen contenido no confiable al igual que una base de datos vectorial, y necesitan las mismas defensas.
• Mantenga y expanda periódicamente un conjunto de pruebas adversarias para la resistencia a la inyección. Las nuevas frases de inyección aparecen regularmente; un conjunto de pruebas estático desde el lanzamiento inicial deja de capturar ataques reales con el tiempo.

C - Ámbito de Herramientas con Privilegios Mínimos

• Proporcione a cada herramienta el input_schema más estrecho que aún cumpla su función. Prefiera enums y valores resueltos internamente sobre parámetros de cadena abiertos para cualquier cosa que se mapee a una acción real.
• Emita una credencial separada y con ámbito para cada herramienta en lugar de una credencial compartida en un agente. Una credencial compartida colapsa el radio de explosión de todo el conjunto de herramientas a lo que esa única credencial puede acceder.
• Valide cada argumento de herramienta en código antes de la ejecución, independientemente de lo que afirme el modelo. Trate los argumentos de llamada de herramienta de Claude como entrada no confiable, de la misma manera que trataría un valor de un cuerpo de solicitud HTTP.
• Limite el radio de explosión de una sola llamada de herramienta con límites de tasa y límites de registros. Limite cuántas veces se puede llamar a una herramienta por sesión y cuántos registros puede tocar una sola llamada.
• Obtenga un segundo revisor, que no haya construido la herramienta, para que apruebe su ámbito antes del despliegue. El modelo mental del autor original de "para qué sirve esto" facilita pasar por alto lo que la herramienta es realmente capaz de hacer.

D - Prevención de Secretos y Exfiltración

• Nunca coloque una credencial en una cadena de prompt, prompt del sistema o argumento de herramienta. Cargue los secretos solo dentro del código de implementación de la herramienta, desde una variable de entorno o un gestor de secretos dedicado, nunca en ningún lugar donde la ventana de contexto del modelo pueda verlos.
• Cree una lista blanca de destinos para cualquier herramienta que pueda enviar datos externamente. Verifique el host o la dirección de destino contra una lista blanca explícita antes de ejecutar, no confíe en un destino que el modelo haya suministrado.
• Cree una lista blanca de los campos que puede contener una carga útil de herramienta, utilizando restricciones de esquema como additionalProperties: False. Esto evita que el modelo construya una llamada fuera de ámbito a nivel de esquema, antes de que su propio código de validación se ejecute.
• Redacte contenido con forma de secreto y con forma de PII antes de que llegue a cualquier registro, mensaje de error o herramienta de observabilidad de terceros. Enrute todos los registros a través de una única función de redacción para que ninguna ruta de código pueda escribir accidentalmente contenido no redactado.
• Registre cada intento de llamada de herramienta, éxito y bloqueo, no solo los exitosos. Un rastro de auditoría completo es lo que le permite reconstruir exactamente lo que sucedió durante un incidente sospechoso.

E - Cumplimiento SOC2 y GDPR

• Envíe solo los campos que un prompt realmente necesita y elimine PII del contexto recuperado antes de que entre en un prompt. Minimizar lo que llega al modelo en primer lugar es el control de cumplimiento más barato y confiable.
• Aplique límites de retención con eliminación automatizada, no solo con un documento de política. Una política de retención escrita sin un trabajo de aplicación o TTL de base de datos es un control de papel que no resistirá una auditoría SOC2 Tipo II.
• Aplique la lógica de retención y borrado a los índices del almacén vectorial, no solo a los registros de conversación. Los pipelines de RAG retienen rutinariamente fragmentos que contienen PII indefinidamente porque el contenido indexado no parece un registro tradicional.
• Registre el acceso a PII con identidad atribuible, no con una entrada genérica a nivel de aplicación. Una auditoría SOC2 busca específicamente quién o qué accedió a datos sensibles; "alguien" no es evidencia suficiente.
• Sea capaz de localizar y exportar o eliminar todas las interacciones de la API de Claude vinculadas al identificador de un usuario específico. Este es el requisito operativo detrás de los derechos de acceso y borrado de datos del sujeto GDPR, y debe probarse antes de que sea necesario, no construirse durante una solicitud activa.

F - Calidad de Recuperación y Fundamentación

• Ajuste el tamaño del fragmento y la superposición según la calidad de recuperación medida, no solo según el costo de incrustación. Un tamaño de fragmento más pequeño es más barato pero puede degradar la calidad de la respuesta de maneras que no se manifiestan hasta que los usuarios lo notan.
• Combine la búsqueda por palabras clave y por incrustación para corpus con contenido sensible a la coincidencia exacta. La búsqueda puramente semántica subestima los códigos de producto, los códigos de error y los nombres propios que la búsqueda por palabras clave captura de manera confiable.
• Instruya explícitamente a Claude para que responda solo del contenido recuperado, y déle permiso explícito para decir que las fuentes no cubren una pregunta. Este único cambio reduce las respuestas seguras y no fundamentadas más que la mayoría de las capas de verificación posteriores.
• Verifique que las citas apunten a fragmentos que realmente se recuperaron, y verifique de forma selectiva que las afirmaciones citadas coincidan con el texto fuente. La presencia de citas por sí sola no garantiza la precisión; el modelo puede citar una fuente real y aun así tergiversarla.
• Mantenga un conjunto de evaluación reservado de consultas reales y rastree la precisión de la fundamentación con el tiempo. La recuperación, la fragmentación y la redacción de prompts cambian a medida que evolucionan un corpus y una base de código; una evaluación única no detecta regresiones.

G - Pipelines Rentables

• Caché de contenido estable y reutilizado genuinamente, nunca contenido recuperado por consulta. Marcar la recuperación volátil como almacenable en caché causa un fallo de caché en cada solicitud mientras se paga el mayor costo de escritura en caché.
• Genere contenido en caché de forma determinista para que el prefijo de caché permanezca idéntico byte a byte entre solicitudes. Incluso una ligera deriva de formato en el contenido "estable" derrota silenciosamente el almacenamiento en caché.
• Verifique que los aciertos de caché se estén produciendo realmente en producción utilizando datos de uso de respuesta. Establecer cache_control no es lo mismo que confirmar que está funcionando; verifique cache_read_input_tokens en tráfico real.

Errores Comunes

• Tratar esta lista como una lista de verificación de lanzamiento única en lugar de una herramienta de revisión continua. El modelo de amenazas, el ámbito de las herramientas y la calidad de la fundamentación cambian a medida que evolucionan las herramientas y las fuentes de datos de un agente; un solo pase en el lanzamiento omite ese cambio. Solución: revise las secciones relevantes cada vez que cambie una herramienta, una fuente de datos o la configuración de recuperación.
• Aplicar estas prácticas de manera desigual entre herramientas dentro del mismo agente. Un equipo que delimita cuidadosamente una herramienta y deja otra sin definir de forma laxa ha delimitado efectivamente el agente a su herramienta más débil. Solución: aplique la lista de verificación completa por herramienta, no una vez por agente.
• Asumir que los controles de cumplimiento (Sección E) son independientes de los controles de seguridad (Secciones B-D). La redacción, el registro de acceso y el ámbito de privilegios mínimos sirven a ambos propósitos simultáneamente; construirlos una vez para la seguridad satisface en gran medida el requisito de cumplimiento también. Solución: diseñe estos controles juntos en lugar de como dos iniciativas separadas.

Preguntas Frecuentes

Relacionados

• Comprender el Modelo de Amenazas de Seguridad y RAG de Claude - el modelo mental que esta lista de verificación operacionaliza.
• Lista de Verificación de Ámbito de Herramientas con Privilegios Mínimos para Agentes Claude en Producción - la versión detallada de la Sección C.
• Consideraciones SOC2 y GDPR para PII en Prompts y Registros - la versión detallada de la Sección E.
• Lista de Verificación de Citas y Fundamentación para Reducir las Alucinaciones de RAG - la versión detallada de la Sección F.

Versiones de Stack: Escrito contra la línea de modelos Claude actual a partir de ~junio de 2026 - Claude Fable 5, Claude Opus 4.8, Claude Sonnet 5 (el predeterminado) y Claude Haiku 4.5 - y el SDK oficial de Python anthropic (última versión 0.x). Los nombres de los modelos, los precios y las versiones del SDK cambian rápidamente; verifique los detalles actuales en platform.claude.com/docs antes de confiar en ellos.