Privacidad y datos en IA: qué no deberías pegar sin pensar

1. Modelo mental

La pregunta “¿puedo pegar esto en una IA?” no se responde por intuición. Empieza clasificando el dato, quién es responsable, qué servicio se usa, qué contrato/configuración aplica y qué necesidad real existe.

Minimización es una técnica de diseño: si para resumir una incidencia no necesitas nombre, teléfono y DNI, elimina esos campos antes del modelo. La mejor protección es no enviar lo que no hace falta.

Privacidad no es sólo un aviso legal. Afecta logs, historial, conectores, archivos temporales, exports, permisos, proveedores y personas que pueden consultar el resultado.

2. Conceptos que debes dominar

3. Workflow paso a paso

4. Ejemplo completo

Caso:resumir tickets de soporte para detectar temas frecuentes.

No necesitas nombre, email, teléfono ni identificadores de cuenta para descubrir categorías. Un preprocesado elimina o sustituye PII, conserva sólo texto necesario y guarda un identificador interno fuera del prompt. El resultado agregado no debe permitir reconstruir la persona original.

Si luego quieres automatizar una acción sobre la cuenta, ese paso se realiza en otro sistema con permisos explícitos, no entregando credenciales al modelo.

5. Matriz de decisión

6. Fallos y límites

Una guía útil también debe decir cuándo detenerse. Estos son los fallos que más cambian la calidad del resultado:

• Copiar datos completos cuando basta un subconjunto.
• Asumir que “enterprise” significa cualquier configuración deseada.
• Guardar prompts en logs indefinidamente.
• Usar conectores con permisos demasiado amplios.
• Enviar secretos o credenciales dentro del contexto.
• Confundir anonimización con borrar el nombre.
• No revisar subprocesadores/región.
• Reutilizar datos para una finalidad distinta sin evaluación.

7. Cómo medirlo

No midas sólo si “parece bueno”. Define una señal observable antes de escalar.

8. Checklist de producción

• Finalidad definida.
• Datos clasificados.
• Minimización aplicada.
• Identificadores eliminados cuando procede.
• Servicio/plan correctos.
• Retención revisada.
• Uso para training comprobado.
• Región/subprocesadores revisados.
• Accesos mínimos.
• Logs y borrado definidos.

9. Ejercicios para convertir lectura en habilidad

• Toma un documento ficticio y marca qué campos eliminarías antes de IA.
• Diseña un pipeline de pseudonimización reversible sólo en sistema interno.
• Revisa qué datos quedan en logs de una integración.
• Escribe un checklist de proveedor con retención, training y región.
• Dibuja el flujo de datos desde usuario hasta modelo y de vuelta.

10. Qué estudiar después

No intentes memorizar toda la IA. Encadena la siguiente pieza cuando resuelva una duda que ya has encontrado en la práctica.

Apéndice A · Preguntas que deberías poder responder

• ¿Qué parte del problema es determinista y cuál necesita juicio probabilístico?
• ¿Qué dato o ejemplo cambiaría tu decisión actual?
• ¿Cómo distinguirás una mejora real de una respuesta simplemente más convincente?
• ¿Qué ocurre cuando faltan datos, la herramienta falla o la respuesta es incierta?
• ¿Qué parte del proceso debe seguir bajo responsabilidad humana?
• ¿Qué coste operativo aparece después del primer prototipo?
• ¿Qué revisarías dentro de 30, 90 y 180 días para evitar que el sistema envejezca?

Si no puedes responder todavía a varias de estas preguntas, no significa que el proyecto esté mal: significa que has encontrado exactamente los huecos que la siguiente iteración debe cerrar. Ese es uno de los usos más valiosos de una guía técnica: convertir incertidumbre difusa en decisiones explícitas.

Apéndice B · Cuatro escenarios para practicar la decisión

No memorices la tabla como si fuera una regla universal. Cambia volumen, riesgo, disponibilidad, privacidad o coste y vuelve a recorrer la decisión. Un sistema robusto documenta qué variables sostienen la elección y cuáles podrían invalidarla.

Apéndice C · Cuaderno de campo para tu propio caso

Copia estas preguntas en un documento y complétalas con un caso real. El objetivo es que el conocimiento deje de estar en la página y pase a tu proceso.

Guarda también dos ejemplos que funcionaron y dos que fallaron. Con el tiempo, esos ejemplos se convierten en un pequeño dataset de evaluación mucho más útil que cualquier memoria informal de “esto parecía ir bien”.

Apéndice D · De prototipo a producción

Una demo responde a la pregunta “¿puede funcionar?”. Producción responde a otras: “¿funciona de forma repetible?”, “¿qué pasa cuando falla?”, “¿quién lo mantiene?”, “¿cómo sabemos que sigue siendo bueno dentro de tres meses?” y “¿podemos revertirlo?”. El salto entre ambas fases suele ser mayor que el salto entre dos modelos.

Antes de escalar, separa cuatro planos.Calidad:casos y métricas.Operación:latencia, cuotas, errores y costes.Gobernanza:permisos, datos, revisión y responsables.Cambio:versiones, fuentes y fechas de reevaluación. Si uno de estos planos no tiene dueño, el riesgo aparecerá precisamente cuando el uso crezca.

• Define un SLO de calidad y uno operativo.
• Registra versión de modelo, prompt, fuentes y configuración.
• Mantén una muestra estable para detectar regresiones.
• Añade un fallback para proveedor, herramienta o dato ausente.
• Decide qué errores se reintentan y cuáles se escalan.
• Presupuesta revisión humana, no sólo tokens.
• Evita permisos permanentes que sólo necesitabas para una prueba.
• Programa una revisión tras cambios de modelo, precio, política o dataset.

Finalmente, observa el sistema con tráfico real. Una mejora offline puede empeorar experiencia, coste o tasa de escalado. Las métricas de esta guía son el comienzo; adáptalas al impacto de tu caso y conserva siempre ejemplos concretos detrás de cada porcentaje.