Ética, gobernanza y propuestas finales
Quién responde por el bot, cómo se supervisa, y cómo cuentas todo el curso en una sola propuesta.
Gobernanza: privacidad, transparencia y supervisión humana
Al terminar esta sesión podrás
- Explicar por qué el usuario tiene derecho a saber que habla con un bot, y qué exige el consentimiento informado.
- Distinguir los tres modos de supervisión humana (in-the-loop, on-the-loop, in-command).
- Decidir el grado de automatización razonable según la sensibilidad del contexto.
- Nombrar los principios de gobernanza que vuelven desplegable un chatbot.
Hasta ayer aprendiste a construir un bot que funciona: recupera tu conocimiento, lo fundamenta y lo cita. Hoy cambias de plano. La pregunta ya no es técnica sino de gobierno: quién decide, quién supervisa y quién responde cuando el bot actúa. Un sistema puede funcionar de maravilla y aun así no poderse desplegar, porque nadie definió sus límites, su supervisión ni cómo se le declara al cliente. Este es el control de calidad ético que vuelve desplegable todo lo anterior.
"Funciona" no es "se puede desplegar". La decisión de poner un bot en producción es de gobernanza, no solo técnica.
Privacidad y consentimiento informado
Tener un dato no da derecho a tratarlo: hace falta una base legal, y en servicio al cliente la más común es el consentimiento. Para ser válido no basta una casilla enterrada en treinta páginas. Debe cumplir cuatro condiciones.
Antes del tratamiento
Se pide el permiso antes de recoger o usar el dato, no después.
Sin coacción
No se condiciona un servicio esencial a que el cliente lo acepte.
Acción afirmativa
Un acto claro de la persona, nunca casillas premarcadas por defecto.
Sabe qué pasa
Conoce qué se recoge, para qué, quién lo trata y cómo ejercer sus derechos.
Además, el consentimiento es específico y revocable: se otorga para un propósito y se puede retirar tan fácil como se dio. Aplicado al bot: si guarda transcripciones con datos personales "para mejorar el servicio", eso es un tratamiento que hay que declarar y, según el caso, consentir. No se puede usar en silencio el historial de chats para entrenar un modelo.
En Lima aplica la Ley N° 29733 de protección de datos personales, cuya autoridad es la ANPD (Ministerio de Justicia). Comparte ADN con el RGPD europeo y la LFPDPPP mexicana: consentimiento informado, finalidad declarada, minimización y derechos del titular.
Transparencia: declarar que es un bot
El usuario tiene derecho a saber que habla con una máquina. Fingir ser humano es engañoso y, ante datos sensibles, agravante; además, en cada vez más jurisdicciones es una obligación legal. La práctica mínima: el bot se presenta como asistente automatizado y ofrece, de forma visible, la ruta hacia un humano.
Trazabilidad y auditoría con citación
Un sistema responsable deja rastro: qué se preguntó, qué fragmentos del corpus se recuperaron, qué respondió y con qué fuentes. La citación del RAG no es solo un adorno para el cliente: es el mecanismo de auditoría. Si una respuesta fue dañina, hay que poder reconstruir por qué la dio y qué documento la fundamentó. Documentación más registros equivalen a auditabilidad.
Sin cita y sin registro no hay auditoría; sin auditoría no hay responsabilidad; y sin responsabilidad no hay despliegue serio en banca, salud o educación.
El humano en el lazo: tres modos de supervisión
La pregunta no es "bot o humano", sino en qué punto del proceso está el humano y qué decisiones nunca le quitamos.
Aprueba antes
Una persona revisa o aprueba antes de una acción sensible: procesar un reembolso, una decisión que afecta a alguien.
Supervisa en vivo
El bot opera solo por defecto, pero el humano observa en tiempo real y puede intervenir.
Gobierna y audita
El humano fija los límites, audita y puede apagar el sistema; gobierna sin estar en cada interacción.
Escalación: saber cuándo rendirse
El bot debe reconocer sus límites. Se escala a un humano cuando no encuentra fundamento (groundedness baja), cuando el usuario lo pide, cuando detecta enojo o toxicidad, o cuando el tema entra en zona sensible. Bien diseñada, la escalación sube el FCR y el CSAT; su ausencia "atrapa" al cliente y genera detractores. Escalar no es fallar: es gobernar el riesgo.
Límites razonables de automatización
No todo proceso debe automatizarse aunque técnicamente se pueda. El criterio es directo: a mayor sensibilidad y mayor daño de un error, menor grado de automatización autónoma.
| Contexto | Qué puede hacer el bot solo | Qué exige un humano |
|---|---|---|
| Salud | Informar horarios, ubicaciones, preparación de exámenes | Nunca diagnóstico, dosis ni interpretación clínica |
| Finanzas / banca | Explicar requisitos, comisiones, preguntas frecuentes de productos | Operaciones con dinero, asesoría de inversión, decisiones de crédito |
| Legal | Orientar sobre trámites, plazos generales, dónde acudir | Asesoría vinculante o interpretación de un caso concreto |
| Educación (ESAN) | Preguntas de admisión, calendarios, reglamentos | Decisiones sobre una persona: beca, sanción, admisión |
Principios de gobernanza, en resumen
Transparencia
El usuario sabe que habla con un bot y ve la ruta al humano.
Trazabilidad
Registros más citas que permiten reconstruir cada respuesta.
Supervisión
Un humano en el punto correcto del lazo, con poder de apagar.
Minimización
Solo los datos necesarios; lo que no está en el índice no se puede filtrar.
Escalación
Regla clara para derivar a una persona ante duda o sensibilidad.
Límite de alcance
Fuera del alcance definido, el bot no decide: informa y deriva.
De fragmentos a propuesta: integración y pitch ejecutivo
Al terminar esta sesión podrás
- Integrar los entregables de la semana en una propuesta única y trazable, no en piezas yuxtapuestas.
- Estructurar la propuesta escrita en ocho secciones, cada una heredada de un módulo del curso.
- Construir un pitch ejecutivo con un storyline claro y defenderlo ante una audiencia no técnica.
- Nombrar los riesgos tú mismo y cerrar con un pedido concreto.
Durante la semana cada taller produjo una pieza suelta: la delimitación de un contexto, un corpus de preguntas frecuentes, una arquitectura con fallback, un gold set con métricas, un tablero de KPIs, un análisis ético. El riesgo natural es entregar esas piezas yuxtapuestas (una al lado de otra) en lugar de integradas (cada una justificando a la siguiente). La diferencia es la trazabilidad: el caso de uso decide qué corpus necesitas, el corpus condiciona la arquitectura, la arquitectura define qué evalúas, la evaluación alimenta los KPIs, y los riesgos éticos modulan el fallback y el alcance.
Una buena propuesta es una sola decisión tomada ocho veces: el problema decide el caso de uso, el caso de uso decide los datos, y así hasta el último renglón. Si cambias el problema, todo lo demás debería cambiar con él.
La propuesta escrita: ocho secciones
Este es el andamiaje. Cada sección hereda de un módulo del curso; apunta a entre seis y diez páginas, sin contar anexos.
| # | Sección | Pregunta que responde | Señal de calidad |
|---|---|---|---|
| 1 | Contexto y problema | ¿Qué duele, a quién y cuánto cuesta hoy? | El dolor está cuantificado (volumen, costo, métrica base), no es genérico |
| 2 | Caso de uso y alcance | ¿Qué resuelve el bot y qué no? | Alcance delimitado con lista explícita de "fuera de alcance" |
| 3 | Arquitectura + fallback | ¿Cómo funciona y qué pasa cuando no sabe? | Flujo RAG con grounding y regla de escalación a humano clara |
| 4 | Datos / corpus | ¿Con qué conocimiento se alimenta y cómo se mantiene? | Fuentes identificadas, dueño del contenido y plan de actualización |
| 5 | Evaluación | ¿Cómo se prueba que responde bien y citado? | Gold set con N preguntas, métricas (precision@k, groundedness) y umbral |
| 6 | KPIs y piloto | ¿Cómo se mide el valor y cómo se lanza? | KPIs emparejados (eficiencia y experiencia); piloto acotado y reversible |
| 7 | Riesgos éticos | ¿Qué puede salir mal y cómo se previene? | Riesgos priorizados por probabilidad por impacto, con mitigación concreta |
| 8 | Factibilidad | ¿Es viable y qué sigue? | Supuestos, recursos, dependencias y un roadmap realista |
Si no puedes nombrar lo que tu bot no va a hacer, todavía no entendiste tu problema. La mejor señal de un proyecto sano es una buena lista de "fuera de alcance".
La rúbrica del proyecto reparte estos criterios con pesos distintos; tenla abierta mientras escribes. La evaluación y los KPIs pesan más porque ahí el curso se juega su tesis: RAG mejora la calidad del servicio solo si se mide.
Abre la rúbrica del proyecto (40%) → · Repasa los casos de sector →
El pitch ejecutivo: vender la propuesta en minutos
La propuesta escrita se lee con calma; el pitch se vive en una reunión para que un decisor diga sí. No es "la propuesta con letra más grande": es una historia orientada a la decisión, con seis tiempos y una sola tarea cada uno.
| # | Tiempo | Tarea (una sola) | Ejemplo de frase |
|---|---|---|---|
| 1 | Problema | Hacer sentir el dolor con un dato | "Atender admisiones nos cuesta X y el 60% son 10 preguntas repetidas." |
| 2 | Solución | Una frase de qué es, sin jerga | "Un asistente que responde con nuestras políticas y cita la fuente." |
| 3 | Valor | Traducir a la métrica del decisor | "Esperamos liberar el 40% de las consultas simples y bajar el esfuerzo." |
| 4 | Evidencia | Mostrar que no es promesa | "Probado contra 50 preguntas reales: 96% respondidas y citadas." |
| 5 | Riesgos | Nombrarlos primero, con mitigación | "Si no sabe, no inventa: deriva a un humano. Datos sensibles, anonimizados." |
| 6 | Pedido | Pedir algo concreto y pequeño | "Pedimos aprobar un piloto de 6 semanas en un canal." |
Quien nombra primero el riesgo controla la conversación. Si dices "el mayor riesgo es que aluciné, por eso exigimos grounding y fallback", proyectas dominio; si lo callas y el evaluador lo descubre, proyectas ingenuidad.
Reglas de una buena presentación
Una idea por diapositiva
Si una slide tiene dos ideas, son dos slides. El detalle vive en la propuesta escrita.
Titular afirmativo
El título es una afirmación, no una etiqueta: "Bajamos el esfuerzo del cliente", no "KPIs".
Empieza por el final
Di la conclusión primero y luego el porqué. La audiencia agradece saber a dónde vas.
Un número que se recuerde
Elige una cifra ancla (el costo actual, el % de deflexión esperado) y repítela.
Ensaya con reloj
El tiempo no se improvisa; no más de una diapositiva por minuto.
Cierra con el pedido
La última frase es el pedido, no "gracias por su atención".
Errores al presentar tecnología a no técnicos
| Error | Cómo se ve | Antídoto |
|---|---|---|
| Jerga sin traducir | "usamos embeddings y un vector store con chunking" | Habla de beneficio: "encuentra el párrafo exacto del manual" |
| Empezar por la arquitectura | El primer slide es un diagrama técnico | Empieza por el dolor de negocio; la arquitectura es evidencia |
| Prometer cero errores | "Nunca se equivoca" | Honestidad: "reduce el error y, cuando duda, escala" |
| No pedir nada | Terminar con "gracias" | Cierra con el pedido concreto y pequeño |
Ensayo del pitch
Para el ensayo en seco con "el gerente escéptico". Elige la duración e inicia.
Presentaciones finales, coevaluación y cierre
Al terminar esta sesión podrás
- Presentar tu propuesta dentro del tiempo, con foco y al nivel de la audiencia.
- Dar y recibir retroalimentación constructiva y coevaluar a tus compañeros con criterios explícitos.
- Mirar el curso completo como un hilo narrativo y discutir qué falta para llevar un RAG a producción.
Formato de las presentaciones
Cada equipo presenta con tiempos fijos y visibles. Un cronómetro proyectado marca el ritmo; el aviso llega a falta de un minuto y de treinta segundos. Pasarse de tiempo es, en sí, un dato evaluable.
| Bloque | Tiempo | Nota |
|---|---|---|
| Encuadre (reglas, rúbrica, coevaluación) | 5 min | La rúbrica ya se conoce desde el inicio del proyecto |
| Por equipo: pitch | 6 min | Cronómetro visible; aviso a los 5 minutos |
| Por equipo: preguntas del jurado y pares | 3 min | El profesor modera, no monopoliza |
| Por equipo: llenado de coevaluación | 1 min | En silencio, mientras pasa el siguiente |
| Síntesis y cierre del curso | 10–12 min | El hilo completo, recorrido de nuevo |
Coevaluación de pares
Coevaluar enseña tanto como presentar: te obliga a aplicar la rúbrica, y eso profundiza tu comprensión de los criterios. Se usa una ficha breve, de tres a cinco ítems en escala de 1 a 5, alineada con la rúbrica: claridad del problema, solidez de la solución, manejo de riesgos, calidad de la presentación, y "una cosa que aprendí de este equipo".
Usa el patrón "lo que funcionó / lo que mejoraría / una pregunta". Empieza por lo concreto que funcionó, redirige al futuro sin humillar, y cierra con una pregunta que haga pensar. Critica la decisión, nunca a la persona.
Síntesis: el hilo del curso, de principio a fin
Recorre la semana como una sola historia, no como cinco días sueltos:
El servicio cuesta
La atención al cliente es cara, repetitiva y desigual. Ahí nace la oportunidad.
Llegan los LLMs
Parecen la solución mágica, pero alucinan, no conocen tus datos y no citan.
Entra RAG
Recupera tu propio conocimiento y fundamenta la respuesta con su fuente.
¿Funcionó?
Sin gold set, sin métricas con umbral y sin KPIs, "funciona bien" es solo una opinión.
¿Es desplegable?
Ética, transparencia y fallback humano vuelven responsable todo lo anterior.
El viaje completo
La propuesta de tu equipo recorre ese mismo hilo, hecho por ti.
La magia no está en el modelo: está en fundamentar, medir y escalar a un humano cuando hace falta. Y en saber dónde no pondrías un chatbot aunque pudieras.
Te llevas tres cosas. Una herramienta: sabes qué es y qué no es un chatbot RAG. Un criterio: sabes cuándo conviene, cómo medirlo y cuándo decir que no. Y un lenguaje: puedes hablar de groundedness con un técnico y de esfuerzo del cliente con un gerente en la misma reunión. Esa traducción entre los dos mundos es lo más valioso y lo más escaso. Gracias por la semana.