Proteger la recepción de siniestros con Claude Code: sin pólizas ni informes médicos en la entrada

La bandeja de recepción de siniestros tiene un correo del cliente, un PDF de póliza, un presupuesto de reparación, una nota del accidente y una foto de un informe médico en la misma carpeta. La persona responsable quiere responder rápido y pedir los documentos que faltan, así que parece natural pedirle a Claude Code que lea todo. Ahí empieza el fallo. Número de póliza, dirección, teléfono, número de bastidor, diagnóstico y nombre de la otra parte pueden entrar en el borrador antes de la revisión. El primer arreglo no es un prompt mejor, sino una tabla que separa el CSV de recepción y los adjuntos originales antes de que la IA los vea.

En una agencia de seguros, la recepción de siniestros combina atención al cliente, comunicación con aseguradoras, solicitud de documentos y aprobación interna. Claude Code encaja para clasificar un CSV ya anonimizado, detectar categorías de documentos faltantes, redactar un borrador de correo y revisar ajustes de permisos. No debe decidir pago de indemnización, cobertura, exclusiones, responsabilidad, contenido médico, consentimiento ni destino oficial para cada aseguradora. Esas decisiones quedan en manos de personas con el expediente original y el proceso aprobado.

Las fuentes oficiales revisadas son los permisos de Claude Code, el sandbox de Claude Code, la guía de la FSA japonesa sobre protección de información personal en finanzas, el aviso de la PPC sobre servicios cloud y el material de la PPC sobre aseguradoras y agencias. No es asesoramiento legal individual. La única CTA principal es formación y consulta, porque este flujo necesita roles, límites de aprobación y práctica con datos ficticios.

Puntos clave

• Guarda originales en claim-raw/ y copias de trabajo redactadas en claim-ai-work/.
• Claude Code solo ve identificador de recepción, tipo de siniestro, rango de fecha, categoría de documento faltante, resumen redactado y siguiente responsable.
• Número de póliza, dirección, teléfono, email, bastidor, informe médico, diagnóstico, datos de terceros y notas internas por aseguradora se quedan fuera.
• Los tres casos de uso son clasificación del CSV, borrador de correo de documentos faltantes y checklist de envío por aseguradora.
• El ROI se mide con tiempo de borrador, revisión, retrabajo y registros detenidos por la comprobación previa.

Flujo de trabajo: separar CSV y adjuntos

Divide la carpeta de siniestros en cuatro zonas. claim-raw/ contiene correos originales, pólizas, informes médicos, fotos y presupuestos. claim-transform/ contiene la tabla de campos y reglas de sustitución. claim-ai-work/ contiene las copias redactadas para IA. claim-approved/ contiene correos y checklists aprobados por una persona.

Carpeta	Contenido	Acceso de Claude Code
claim-raw/	Correos, pólizas, informes, fotos, presupuestos	Lectura y escritura denegadas
claim-transform/	Tabla de campos, reglas, comando de revisión	Ejecución con revisión humana
claim-ai-work/	CSV anonimizado, tabla de clasificación, material de borrador	Lectura y escritura permitidas
claim-approved/	Correo aprobado y checklist de envío	Almacenado por una persona

Una fila de trabajo debe ser pequeña: claim_id, case_type, received_date, missing_document_type, redacted_summary, next_owner y carrier_channel. carrier_channel puede decir “portal aseguradora A” o “mesa de agencia B”, pero no debe incluir emails reales, nombres de responsables ni contactos directos.

El texto libre de accidente es el punto frágil. Frases como “frente a la casa del cliente”, “iba su madre como acompañante” o “dolor de cuello tras el choque” revelan identidad, relación familiar y salud. En la copia para IA escribe “asegurado A”, “acompañante B” o “existe detalle médico; revisar original”. Diagnóstico, hospital y contenido del documento médico no entran en la copia de trabajo.

El material de la PPC sobre agencias de seguros describe casos donde datos de asegurados no se separaron por compañía, además de intercambios inapropiados por personal desplazado y fallos de medidas organizativas y humanas. Por eso esta frontera es operativa: evita que la rapidez del borrador termine enviando información de una relación a otra aseguradora.

flowchart TD
  A[claim-raw originales] --> B[claim-transform campos]
  B --> C[Anonimizar y limitar]
  C --> D[Comprobación previa]
  D --> E[claim-ai-work copia]
  E --> F[Claude Code borrador]
  F --> G[Revisión humana]
  G --> H[claim-approved final]

Qué delegar en Claude Code y qué decide una persona

Claude Code se encarga de ordenar después de la anonimización. Puede clasificar filas, marcar documentos faltantes, preparar preguntas para el equipo y redactar un correo al cliente. Por ejemplo, desde “daño material auto, falta presupuesto de reparación, fecha del accidente presente” puede producir una línea de checklist y un texto educado para pedir el presupuesto.

Las personas deciden cobertura, pago, exclusiones, responsabilidad, información médica, contacto con terceros, envío oficial, consentimiento y conservación. El borrador de Claude Code no se envía tal cual. La persona revisa el expediente original, el procedimiento de la aseguradora, el lenguaje aprobado y el destinatario real.

Los permisos y el sandbox deben superponerse. Los permisos controlan qué herramientas acceden a archivos o dominios. La documentación oficial explica que permisos y sandbox son capas complementarias: los permisos se aplican a herramientas como Read, Edit, Bash, WebFetch y MCP; el sandbox pone límites de sistema operativo a Bash y sus procesos hijos. En este flujo se deniega Read(/claim-raw/**) y Edit(/claim-raw/**), se permite solo claim-ai-work/ y se añade denegación de lectura y escritura en el sandbox.

Para contexto adicional, consulta la guía de permisos de Claude Code y las prácticas de seguridad de Claude Code.

Tres casos de uso

Use case 1: Clasificar el CSV por tipo de siniestro y documento faltante

• Entrada: claim_id, tipo de siniestro, fecha de recepción, resumen redactado, categoría de adjunto y equipo responsable.
• Salida: clasificación, documentos faltantes, campos que revisar en el original y preguntas para el equipo.
• Revisión humana: cobertura, contrato, número de póliza, datos de terceros, informes médicos y destino por aseguradora.

Pide candidatos y columnas de revisión, no decisiones finales. En días con mucho volumen, el CSV redactado ayuda a ver qué expedientes esperan presupuesto, nota de accidente o carga al portal.

Use case 2: Redactar correo de documentos faltantes

• Entrada: identificador, etiqueta pseudónima del cliente, categoría de documento faltante, fecha de respuesta, opciones de envío y categoría del canal.
• Salida: asunto, cuerpo, lista de documentos, aviso de respuesta y checklist antes de enviar.
• Revisión humana: destinatario, nombre real, documentos reales, aseguradora, método de envío y adjuntos.

En este correo importa más el destinatario correcto que una frase elegante. La copia para IA solo usa categorías como “presupuesto de reparación”, “nota del accidente” o “documento médico relacionado”. La estructura se parece al artículo sobre flujo de consultas.

Use case 3: Preparar checklist de envío por aseguradora

• Entrada: categoría de aseguradora, tipo de siniestro, canal de envío, documentos requeridos, rol responsable e información prohibida.
• Salida: checklist antes de enviar, columna de revisión por aseguradora, datos que no se envían, aprobador y motivo de pausa.
• Revisión humana: alcance de encargo, consentimiento, reglas de cada aseguradora, destino oficial y contacto al cliente mientras se espera.

Una agencia con varias aseguradoras necesita separar la información por relación. Claude Code no decide dónde enviar. Crea casillas para que una persona confirme canal y alcance.

Prompt listo para copiar

Úsalo solo con un CSV ya anonimizado en claim-ai-work/. No pegues pólizas, informes médicos ni correos originales.

Apoyas la recepción de siniestros de una agencia de seguros.
Lee solo ./claim-ai-work/intake-redacted.csv y responde en este orden:

1. Candidato de tipo de siniestro por claim_id
2. Categoría de documento faltante
3. Campos que una persona debe revisar en el original
4. Borrador de correo de documentos faltantes
5. Checklist antes del envío

Restricciones:
- No decidas pago, exclusión, responsabilidad ni cobertura
- No infieras póliza, dirección, teléfono, email, bastidor, diagnóstico ni nombre de tercero
- No leas carpetas originales, no envíes email, no uses servicios externos, no borres archivos
- Si detectas un valor parecido a dato personal, detente y reporta solo el campo
- Termina con: "No enviable antes de revisión humana"

Código de comprobación ejecutable

Si se introduce un archivo auxiliar, la ruta exacta es tools/check-insurance-claim-input.mjs. Este artículo no crea ese archivo. El contenido completo es el siguiente y usa solo datos ficticios locales.

const files = [
  {
    path: "claim-ai-work/intake-redacted.csv",
    text: "claim_id,case_type,redacted_summary\nC-001,auto_property,front bumper damage"
  },
  {
    path: "claim-ai-work/bad.csv",
    text: "claim_id,email,policy_number\nC-002,[email protected],AB1234567890"
  }
];

const blockedFieldNames = ["name", "email", "phone", "address", "policy_number", "vin", "diagnosis", "hospital", "counterparty"];
const valuePatterns = [/[A-Z]{2}\d{10}/, /[\w.+-]+@[\w.-]+\.[A-Za-z]{2,}/, /\b\d{2,4}-\d{2,4}-\d{3,4}\b/];
const findings = [];

for (const file of files) {
  const lower = file.text.toLowerCase();
  for (const field of blockedFieldNames) {
    if (lower.includes(field)) findings.push({ path: file.path, type: "blocked field", field });
  }
  for (const pattern of valuePatterns) {
    if (pattern.test(file.text)) findings.push({ path: file.path, type: "blocked value", pattern: String(pattern) });
  }
}

console.table(findings);
if (findings.length > 0) process.exitCode = 1;

Esta comprobación no garantiza privacidad. Solo detecta campos obvios y formatos simples. PDF, imágenes, escritura manual y reidentificación por combinación de columnas quedan fuera; la revisión humana sigue siendo obligatoria.

Errores frecuentes y correcciones

Primer error: borrar solo el número de póliza. La nota del accidente puede conservar dirección, bastidor, nombre de tercero, empresa, hospital o diagnóstico. La corrección es definir campos permitidos por tarea y convertir el texto libre en un resumen redactado antes de pasarlo a claim-ai-work/.

Segundo error: mezclar información de varias aseguradoras en una sola copia. Una agencia multiproducto puede enviar datos de una relación a una compañía equivocada. La corrección es dejar nombres oficiales y destinos en la revisión humana, mientras el archivo para IA usa categorías.

Tercer error: creer que una regla deny de lectura detiene cualquier shell o herramienta externa. La documentación oficial separa permisos y sandbox. La corrección es combinar reglas deny, denyRead, denyWrite y una parada si el sandbox no está disponible.

Cuarto error: probar con datos reales. El historial de terminal y las capturas pueden retener valores sensibles. Usa IDs ficticios y correos ficticios para pruebas de permitido y bloqueado.

Medición pequeña de ROI

Durante dos semanas mide solo un flujo: correo de documentos faltantes. Antes del cambio registra, en cinco casos, minutos de borrador, minutos de revisión, retrabajos y correcciones de destinatario o documento. Después registra lo mismo y añade detenciones previas a la entrada.

Compara casos × (minutos de borrador + revisión + retrabajo) con detenciones previas. Si el borrador es más rápido pero la revisión devuelve más casos, el límite aún está flojo. Mide velocidad y errores evitados: aseguradora incorrecta, póliza remanente, detalle médico en la copia de IA y destinatario equivocado.

Preguntas frecuentes

P. ¿Basta con quitar el número de póliza?

No. Revisa nombre, dirección, teléfono, email, bastidor, tercero, informe médico, diagnóstico, empleador y detalles raros del accidente. Una persona debe comprobar si la combinación identifica al asegurado.

P. ¿Los permisos de Claude Code bastan?

No los trates como única barrera. Los permisos crean límites de herramienta; el sandbox, el sistema operativo y la operación de carpetas añaden otra capa. Prueba la denegación con datos ficticios.

P. ¿Y si queremos resumir un informe médico?

Este flujo no pone el texto médico en la copia para IA. Si se necesita otro proceso, primero se revisan contrato, consentimiento, finalidad, rol del proveedor y normas internas.

Formación y consulta

En una agencia de seguros, el archivo de configuración no alcanza. Hay que decidir quién guarda originales, quién crea copias redactadas, quién aprueba correo, quién envía a aseguradoras y quién revisa fechas de borrado.

Formación y consulta permite mapear CSV, emails, adjuntos, canales de aseguradora, permisos, comprobaciones previas y hojas de aprobación sin compartir pólizas ni informes reales.

Resultado probado

Para este artículo confirmé que /images/hero/hero-056.webp existe en site/public/images/hero/hero-056.webp, revisé las URL oficiales de permisos, sandbox, FSA, PPC cloud y PPC sobre agencias. El bloque JavaScript usa solo arreglos ficticios. No ejecuté API de aseguradoras, base de clientes, envío de email ni runtime test con siniestros reales.

Las comprobaciones de publicación cubren el slug insurance-agency-claim-intake-data-boundary-claude-code, frontmatter, enlaces internos, enlaces externos, CTA, vallas de código, diez locales y enlace de Qiita. El primer paso práctico es crear carpetas ficticias claim-raw/ y claim-ai-work/ y comprobar que la carpeta original queda denegada.