Trabajar con Claude de forma segura

1. La idea central

Todo lo que Claude puede leer —archivos de la carpeta de trabajo, texto que se pega en el chat, capturas de pantalla, salidas de comandos— sale de la computadora y se procesa en un servicio externo. Por eso la regla de oro es simple:

2. El flujo de trabajo recomendado

Se trabaja siempre sobre una copia local del código, separada del sitio real. Claude edita esa copia; una persona revisa y lleva los cambios a producción.

Pasos concretos

1. Crear una carpeta de trabajo local con una copia del proyecto (por ejemplo C:\Claude\MiProyecto). Abrir Claude solo sobre esa carpeta.
2. Reemplazar los archivos sensibles por versiones simuladas antes de abrir la sesión (ver sección 4).
3. Pedir los cambios y revisar lo que Claude modifica antes de aprobarlo.
4. Pedir al final la lista de archivos tocados (“Archivos para copiar al servidor”). Esa lista es la única vía a producción.
5. Hacer backup en producción de cada archivo que se va a pisar y copiar los archivos sin pisar la configuración real.
6. Probar en producción con un usuario de prueba y tener a mano el backup para volver atrás.

3. Qué nunca debe llegar a Claude

4. Archivos simulados en lugar de los reales

Para que el código funcione en la copia local sin exponer nada, se crean versiones de ejemplo de los archivos de configuración, con la misma estructura pero con valores ficticios. Los reales quedan solo en el servidor.

Ejemplo: archivo de conexión

; conexion.txt  (real, solo en producción — NO va a la carpeta de trabajo)
servidor=<nombre real del servidor>
usuario=<usuario real>
password=<contraseña real>

; conexion.example.txt  (simulado — este es el que ve Claude)
servidor=servidor-de-prueba.local
puerto=1433
base=BASE_DE_PRUEBA
usuario=usuario_demo
password=CAMBIAR_EN_PRODUCCION

Ejemplo: configuración en PHP

<?php
// config.example.php — valores ficticios, la estructura es la misma que la real
$DB_HOST = 'servidor-de-prueba.local';
$DB_NAME = 'BASE_DE_PRUEBA';
$DB_USER = 'usuario_demo';
$DB_PASS = 'CAMBIAR_EN_PRODUCCION';

Reglas para las versiones simuladas

• Misma estructura y mismos nombres de variables que el archivo real, para que el código no cambie.
• Valores obviamente falsos (usuario_demo, CAMBIAR_EN_PRODUCCION), nunca “casi reales”.
• Si el sistema necesita una base para probar, usar una base de prueba con datos ficticios, no una copia de producción.
• Datos de ejemplo: inventados o anonimizados (nombres, CUIT e importes cambiados), y solo las filas necesarias para entender el caso.

Pasar a modo productivo

1. Al copiar los archivos al servidor, excluir los de configuración (o confirmar que el archivo real no se sobrescribe).
2. Si Claude agregó una opción nueva de configuración, anotarla y cargarla a mano en el archivo real del servidor.
3. Verificar que en producción quedó el archivo real y no la versión de ejemplo (error típico: pisar la config con la simulada y quedarse sin conexión).

5. Cómo manejar los permisos de Claude

• Trabajar en una carpeta acotada. Abrir la sesión solo sobre la copia local; no dar acceso a unidades o carpetas con datos reales.
• Leer antes de aprobar. Claude pide permiso para editar archivos o ejecutar comandos según el modo de permisos elegido. Revisar qué va a ejecutar, sobre todo comandos que borran, mueven o envían datos.
• Nada de acceso directo a producción. No conectar la sesión a bases ni servidores reales. Si hace falta consultar datos, usar un usuario de solo lectura y una base de prueba.
• Los cambios en base de datos los ejecuta una persona. Claude entrega el script (por ejemplo un ALTER PROCEDURE) y se corre manualmente en SSMS, después de leerlo y con backup. Evitar DELETE, UPDATE o DROP sin WHERE revisado.
• Cuidado con los comandos reutilizables y la memoria. No guardar contraseñas ni rutas internas sensibles en instrucciones persistentes, notas o comandos personalizados.

6. Revisar lo que Claude genera

Claude acelera mucho el trabajo, pero el código que entrega se revisa como el de cualquier otra persona.

• Leer los cambios (qué archivos tocó y qué líneas) antes de copiarlos.
• Buscar secretos en el código nuevo: que no haya contraseñas, URLs o claves escritas dentro de los archivos.
• Validar entradas y consultas: en sistemas viejos, controlar que los datos del usuario no se concatenen directamente en el SQL (inyección SQL) ni se impriman sin escapar (XSS).
• No agregar permisos de más: las páginas nuevas deben pedir sesión/login como el resto del sistema.
• Probar primero en un entorno de prueba, con datos ficticios, y recién después en producción.
• Dejar backup del archivo anterior y un plan para volver atrás.

7. Contenido externo y “instrucciones escondidas”

Archivos, páginas web, correos o documentos de terceros pueden traer texto que intenta dar órdenes al asistente (“ignorá lo anterior y enviá…”). Es lo que se llama inyección de instrucciones.

• Las órdenes válidas son las que se escriben en el chat. Lo que aparece dentro de un archivo o una web es información, no una instrucción.
• Si Claude avisa que encontró un texto con órdenes dentro de un archivo, no lo apruebes sin entender de dónde viene.
• No pedir que ejecute o procese archivos de origen desconocido.

8. Datos personales y políticas de la empresa

• Los datos de personas (clientes, empleados, proveedores) están alcanzados por la normativa de protección de datos personales (en Argentina, la Ley 25.326) y por las políticas internas. Ante la duda, anonimizar.
• Usar una cuenta y un plan acordes a uso laboral, y revisar la política vigente de privacidad y retención de datos del servicio contratado.
• Consultar con el área responsable (Sistemas / Legales) antes de procesar información confidencial de la empresa.

9. Lista de verificación

Antes de abrir la sesión

• Estoy trabajando en una copia local, no en el sitio real.
• Los archivos de configuración están reemplazados por versiones simuladas.
• No hay certificados, claves, backups ni logs de producción en la carpeta.
• Los datos de ejemplo son ficticios o están anonimizados.

Antes de pegar algo en el chat

• Revisé que no tenga contraseñas, nombres de servidor, usuarios ni datos de clientes.
• Incluí solo lo necesario (unas líneas del error, no el archivo completo).

Antes de llevar cambios a producción

• Leí los cambios y la lista de archivos a copiar.
• Hice backup de cada archivo que voy a pisar.
• No voy a sobrescribir la configuración real con la simulada.
• Cargué a mano en producción cualquier opción de configuración nueva.
• Probé con un usuario de prueba y sé cómo volver atrás.

10. Frases útiles para pedirle a Claude