Ética, sesgos y confidencialidad

Conoce exactamente qué envías, cuánto vale legalmente el código generado y cómo los sesgos del modelo orientan tus decisiones técnicas.

10 min · 3 preguntas

Cada prompt es una transmisión de datos a un tercero. Antes de usar un asistente en un contexto profesional, tres preguntas deben tener una respuesta documentada. Retención: ¿cuánto tiempo conserva el proveedor tus conversaciones, y quién puede acceder a ellas (soporte, seguridad, orden judicial)? Entrenamiento: ¿se usan tus datos para entrenar modelos futuros, y está activada la exclusión (opt-out) en tu cuenta? Los planes de consumo y los planes de empresa casi siempre difieren en este punto. Contrato: ¿te permiten tu empresa o tus clientes transmitir este código, sabiendo que las cláusulas de confidencialidad que firmaste también se aplican a un prompt? Un fragmento de código puede parecer inofensivo; combinado con nombres de dominio internos, estructuras de tablas y mensajes de error con rutas completas, describe tu sistema de información.

La buena práctica es la minimización: enviar solo lo estrictamente necesario para el razonamiento. Es una competencia en sí misma (construir un ejemplo reproducible mínimo con nombres genéricos) y tiene una virtud pedagógica inesperada: aislar un problema para describirlo de forma abstracta te obliga a entenderlo. El siguiente prompt convierte esta restricción de confidencialidad en un ejercicio diagnóstico.

Contexto: trabajo con código propietario que no puedo compartir. Describiré mi problema de forma abstracta, con nombres genéricos y sin pegar el código real.

Descripción: [PSEUDOCÓDIGO de la estructura relevante, MENSAJE DE ERROR con rutas e identificadores enmascarados, VERSIONES de las bibliotecas implicadas].

Tu misión:
1. Si mi descripción es demasiado vaga para razonar sobre ella, dime exactamente qué información te falta y por qué: yo decidiré si puedo proporcionarla de forma anonimizada.
2. Razona solo sobre mi descripción: nunca me pidas que pegue el archivo completo.
3. Propón hipótesis sobre la causa, ordenadas por probabilidad, y para cada una una prueba precisa que pueda ejecutar en local para confirmarla o descartarla.

Formato: una tabla de hipótesis / probabilidad / prueba de verificación. Volveré con los resultados de las pruebas.

Segundo expediente: la licencia del código generado. La ley no está zanjada y varía según la jurisdicción, pero tres hechos están establecidos. Uno: los modelos se entrenan con código bajo licencias muy diversas, incluidas licencias copyleft como la GPL, y pueden reproducir fragmentos muy próximos a su fuente, especialmente para algoritmos famosos o fragmentos muy duplicados. Dos: en varias jurisdicciones, una salida puramente mecánica sin aporte creativo humano es difícil de proteger por derechos de autor, lo que socava tus reclamaciones sobre el código aceptado tal cual. Tres: algunos proveedores ofrecen indemnización contractual en caso de una reclamación por infracción, y filtros que bloquean salidas demasiado próximas al corpus: comprueba que estas protecciones están en tu plan, no solo en el folleto. En la práctica: cuanto más largo, específico y sin editar es un fragmento generado, mayor es el riesgo legal.

Tercer expediente: los sesgos. Un modelo reproduce las regularidades estadísticas de su corpus, y tres sesgos afectan directamente a tus decisiones técnicas. El sesgo de popularidad: las soluciones sobrerrepresentadas en los datos (frameworks dominantes, patrones que estuvieron de moda hace dos años) se recomiendan por defecto, incluso cuando tu contexto pide otra cosa; el corpus siempre va un paso por detrás del estado del arte. El sesgo de adulación: los modelos están optimizados para complacer al usuario y tienden a validar tu premisa; pregunta "¿por qué mi enfoque de microservicios es el correcto?" y obtendrás confirmaciones, no una opinión contraria. El sesgo de autoridad invertida: la fluidez del tono produce una impresión de certeza no correlacionada con la fiabilidad. La contramedida es procedimental: forzar la contradicción.

Acabas de recomendarme [SOLUCIÓN O TECNOLOGÍA]. Antes de decidir, cambia de postura: ahora eres un ingeniero experimentado encargado de argumentar EN CONTRA de esta recomendación.

1. Da los 3 mejores argumentos en contra de tu propia respuesta, cada uno ilustrado con un escenario concreto en el que falla.
2. Cita al menos una alternativa seria que no habías mencionado, y explica con honestidad por qué estuvo ausente de tu primera respuesta.
3. Evalúa cuánto debe tu recomendación inicial a la popularidad de esta solución en tus datos de entrenamiento, más que a mi contexto específico, que te recuerdo: [TU CONTEXTO: tamaño del equipo, restricciones, configuración existente].

Formato: dos columnas A favor / En contra, y luego tu recomendación revisada en una frase, con tu nivel de confianza y qué podría cambiarlo.

Prueba de conocimientos

Comprueba que has retenido los puntos clave de esta lección.

1. Antes de pegar el código de tu empresa en un asistente de IA, ¿qué deberías comprobar primero?
   • Que el fragmento no supere el tamaño máximo de contexto
   • La política de retención y de entrenamiento del proveedor, así como tus obligaciones contractuales de confidencialidad
   • Que el lenguaje del código esté bien soportado por el modelo
2. ¿Por qué el código generado por un modelo plantea una cuestión de licencia?
   • Porque todo el código generado se coloca automáticamente bajo la GPL
   • Porque el modelo puede reproducir fragmentos muy próximos a código con licencia, cuyas obligaciones pueden entonces aplicarse a tu proyecto
   • Porque el código generado siempre pertenece al proveedor del modelo
3. ¿Qué es el sesgo de popularidad de un modelo?
   • La tendencia a favorecer las respuestas de los usuarios más activos
   • La tendencia a recomendar soluciones sobrerrepresentadas en los datos de entrenamiento en lugar de la más adecuada a tu contexto
   • La tendencia a halagar al usuario validando sus premisas