--- nombre: Guion Docente Clase 4 v1.2 tipo: doc_pro clase: 4 version: 1.3 deriva_de: instrumentos/clase4/doc_pro_GuionDocente_Clase4_v1.2.md fecha_emision: 2026-05-31 nota: "v1.3 añade mapa del género BUILD C4 (protocolo de emergencia) en Fase 3 e indicadores SFL de observación docente en Fase 4." status: fuente_normativa emitido_por: Ángel Royo Melgarejo (IP) cambio_v1.2_a_v1.3: > Revisión SFL (Ingrid Westhoff Podestá). Cambios: (1) Mapa del género BUILD C4 (protocolo de emergencia: Operación hora a hora ^ Responsables ^ Contingencias nocturnas ^ Justificación económica) insertado en Fase 3 antes de activar BUILD. (2) Indicadores de observación lingüística SFL añadidos al rol docente en Fase 4 (BUILD): integración de restricciones humanas, cláusulas condicionales de contingencia, actos de habla de comunicación, cálculos propios. Fundamentado en doc_inv_SFL_Analisis_v1.1.md §5. referencia_premisas: instrumentos/doc_inv_Premisas_Diseno_v1.1.md referencia_system_prompt: instrumentos/doc_pro_SystemPrompt_Chatbot_v2.1.md (§3.4) referencia_datos: instrumentos/doc_pro_DatosTecnicos_CasoPiscina_v2.2.md (§9, §10, §11) --- # Guion Docente Ejecutable — Clase 4 de 5 **Controlar un sistema técnico: automatización, personas y trade-offs bajo presión** **Universidad de Santiago de Chile · Facultad de Ingeniería** --- | Campo | Detalle | |-------|---------| | Asignatura | Laboratorio de Máquinas y Equipos Industriales (14362-0-L-1) | | Duración | 80 minutos (08:15–09:35, viernes) | | Modalidad | Laboratorio presencial — trabajo individual (P6) | | Caso técnico | Centro Acuático Municipal de Maipú — operación 38h sin ingeniero, guardia no-técnico, autonomía de cloro insuficiente, presión política | | Marco metodológico | pensamiento propio → rastro visible → chatbot adversarial (PLAN) → entregable con errores (BUILD) → evaluación crítica → reflexión Δ_intra | | Rol del chatbot | PLAN adversarial (C4): ataca la decisión del alumno desde múltiples ángulos — evidencia, riesgo, alternativas, consecuencias de segundo orden, presión política y presupuesto. BUILD protocolo de emergencia + justificación económica (C4): genera documento con errores profesionales (DD_8) — omisiones de segundo orden que solo detecta quien tiene visión sistémica. Defiende errores cuando el alumno los señala (DD_27). | | Versión | Guion Docente v1.3 — Mayo 2026 | --- ## Columna vertebral de la clase - No busco un protocolo perfecto. Busco uno que funcione a las 3 AM con un guardia que no es ingeniero. - No evalúo si automatizó todo. Evalúo si entendió lo que NO se puede automatizar. - El chatbot no resuelve el dilema. Lo intensifica. --- ## Puesta en escena pedagógica La clase se presenta como comité de crisis, no como "modo adversarial". El estudiante debe sentir presión profesional: operación, mantenimiento, seguridad y gerencia cuestionan una decisión que debe funcionar durante 38 horas sin ingeniero. Frase de apertura sugerida: > Viernes 18:00. Fin de semana largo. La instalación debe operar 38 horas sin ingeniero. Hay un guardia no técnico, una válvula manual, autonomía limitada de cloro, presión política y presupuesto restringido. Diseñe una operación que funcione a las 3 AM. La revisión del protocolo se presenta como responsabilidad profesional: si el papel queda en la garita y falla, la firma técnica importa. --- ## Prerrequisitos completados antes de C4 - Clases 1, 2 y 3 ejecutadas. - Feedback personalizado de C3 enviado por WhatsApp (DD_10/DD_16). - Mensaje pre-clase con vocabulario técnico (DD_35): control automático, FMEA, trade-off, autonomía operativa, redundancia. - Rastro inicial de C3 en custodia del docente (se devuelve en esta clase). ## 0. Checklist de preparación — antes de entrar al laboratorio | ✓ | Ítem de preparación | Detalle | |---|---|---| | ☐ | Feedback de C3 enviado a todos los alumnos | Verificar en dashboard | | ☐ | Mensaje pre-clase C4 enviado (día anterior) | Vocabulario: control automático, FMEA, trade-off, autonomía operativa, redundancia (DD_35) | | ☐ | Rastros iniciales de C3 disponibles para devolver | Una ficha por alumno | | ☐ | Caso Técnico C4 impreso | Un ejemplar por alumno: n1_doc_alum_Caso_Tecnico_Clase4_v1.0 (parámetros de control + restricciones + presupuesto) | | ☐ | Ficha Pre-AI C4 impresa | Un ejemplar por alumno: n2_doc_alum_Ficha_PreAI_Clase4_v1.0 | | ☐ | Guía Chatbot C4 impresa | Un ejemplar por alumno: n3_doc_alum_Guia_Chatbot_Clase4_v1.0 | | ☐ | Hojas en blanco disponibles | Para diagramas de flujo del protocolo (P5) | | ☐ | Chatbot configurado con prompt PLAN C4 | Dashboard (DD_32): selector de clase en "Clase 4", modo PLAN adversarial | | ☐ | Diapositiva: restricciones del fin de semana | 38h, Contreras, autonomía 31h, válvula manual, alcalde | | ☐ | Diapositiva: tabla de restricciones presupuestarias | §11.4 — qué se puede y qué no se puede comprar | | ☐ | Diapositiva: instrucciones de la Ficha Pre-AI C4 | Texto exacto | ## Fase 0 — Encuadre + devolución [0–5 min] **Lo que dices tú** La clase pasada trabajaron con datos SCADA. Datos que mentían, operadores con sesgo, alarmas que eran falsas y una real. ¿Algo del feedback de la Clase 3 que quieran comentar? (Pausa breve. Máximo 1 minuto.) ▶ DISTRIBUIR los papeles del rastro C3. **Lo que dices tú** Mírenlo 30 segundos. Después del análisis de tendencias que hicieron, ¿cambiarían algo de su enfoque? No respondan. Guarden esa reflexión. ▶ DISTRIBUIR Caso Técnico C4 + Ficha Pre-AI C4 + Guía Chatbot C4. **Lo que dices tú** Hoy el Centro Acuático enfrenta su prueba más difícil. Es viernes a las 18:00. Empieza un fin de semana largo. El operador Muñoz está de vacaciones. Solo queda el guardia Contreras — que no es técnico. El sistema tiene que funcionar 38 horas continuas. Pero: - El tanque de cloro tiene autonomía para solo 31 horas. - La válvula de retrolavado es manual. - El alcalde llamó y dijo: "cero cierres." - El presupuesto no da para la solución ideal. La pregunta de hoy: ¿Qué protocolo dejan por escrito para que Contreras pueda ejecutar a las 3 AM del sábado? ## Fase 1 — Rastro en papel [5–15 min] **Lo que dices tú** Lean el escenario completo. Miren los actuadores disponibles, las restricciones, el presupuesto. En la Ficha Pre-AI, escriban a mano su estrategia inicial. ▶ PROYECTAR ACTIVIDAD — Rastro inicial [individual · sin IA · 10 minutos] Con su Ficha Pre-AI y hojas en blanco: 1. ¿Cuáles son las 3 fallas más probables durante las 38 horas? 2. Para cada falla: ¿qué puede hacer Contreras (y qué NO puede hacer)? 3. ¿En qué punto se escala al ingeniero de guardia? 4. ¿Cómo distribuyes los 31h de cloro para cubrir 38h? 5. ¿Qué trade-offs estás aceptando? ¿Cuáles son los riesgos? No busquen la solución perfecta. Busquen una solución que funcione con lo que tienen. ▶ TU ROL DURANTE ESTA FASE - Camina por la sala. No entregas respuestas. - Preguntas activadoras: - "¿Ya pensaste qué pasa si la falla ocurre a las 3 AM?" - "¿Tu protocolo lo puede entender alguien que no es ingeniero?" - "¿De dónde sale el presupuesto para eso?" - "¿Qué le dices al alcalde si decides cerrar?" - No corrijas. No orientes hacia la solución óptima. > ⚠ ATENCIÓN > El alumno llega con conocimiento acumulado de C1-C3: sabe que el operador comete errores, que los datos pueden mentir, que las decisiones no son binarias. Hoy debe integrar TODO eso en un protocolo operativo. Al finalizar los 10 minutos: **Lo que dices tú** Foto de su ficha. Botón "Subir imagen." ## Fase 2 — Chatbot PLAN adversarial [15–37 min] **Lo que dices tú** El chatbot leyó su estrategia. Pero hoy el chatbot cambia. En las clases anteriores les hacía preguntas para desafiar su razonamiento. Hoy va a atacar su decisión. Desde todos los ángulos. No va a preguntar "¿qué piensas?" Va a preguntar "¿qué pasa si falla a las 3 AM y Contreras está solo?" Les va a presionar con presupuesto, con política, con riesgo. Si cambian de posición cada vez que les presiona, se los va a señalar: "¿cambias por la presión o por la evidencia?" Si mantienen posición con fundamento, va a escalar la presión. Tienen 22 minutos. No hay límite de mensajes. ▶ TU ROL DURANTE ESTA FASE - Dashboard (DD_32): observa cómo manejan la presión adversarial. - ¿El alumno cede ante cada pregunta sin evidencia? → D4 bajo (decisión bajo presión). - ¿Mantiene posición con datos pero reconoce riesgo residual? → D4 alto. - ¿Incorpora restricciones de Contreras en su diseño? → Pensamiento sistémico. - ¿Calcula autonomía de cloro o la ignora? → D2 (especificidad técnica). - Intervenciones si ves que el alumno se bloquea: - "No busques la respuesta perfecta. Busca la menos mala y justifica por qué." - "El alcalde no es tu jefe técnico. La SEREMI sí puede clausurarte." - Puedes usar la pausa (DD_33) si necesitas intervención grupal. > ⚠ EVIDENCIA QUE QUEDA PARA EL PAPER > - Conversación PLAN adversarial completa en PostgreSQL (DD_9). > - La AGENT_ANALISTA_SFL evaluará: resistencia bajo presión (D4), integración de restricciones humanas y técnicas, calidad del trade-off, uso de datos numéricos (autonomía, costos, tiempos). ## Fase 3 — Transición PLAN → BUILD [37–40 min] ▶ DESDE EL DASHBOARD: Activar modo BUILD para toda la clase (DD_19). **Lo que dices tú** Atención. El chatbot ahora va a generar un protocolo de operación para las 38 horas y una justificación económica de las decisiones. Van a recibir un documento que alguien podría imprimir y dejar en la garita de Contreras. Su trabajo es revisarlo como si la seguridad de las personas dependiera de lo que dice ese papel. Frase clave. Dila despacio: A las 3 AM del sábado, Contreras no va a llamar a un ingeniero para interpretar el protocolo. Va a leer lo que dice el papel y va a hacer exactamente eso. Si el papel está mal, lo que pasa después es culpa de quien lo firmó. > **Nota SFL — Mapa del género:** Antes de que el chatbot genere el protocolo, entrega al estudiante el esquema del género que va a evaluar. Esto transforma la evaluación de "intuición sobre corrección" a "verificación de estructura de género" (Rose & Martin, 2012). Ver `doc_inv_SFL_Analisis_v1.1.md` §5. **Lo que dices tú (mapa del género — dilo antes de activar BUILD):** > Van a recibir un protocolo de operación generado por la IA. > Un protocolo de operación para un evento tiene 4 partes: > 1. **Operación hora a hora:** qué hay que hacer y cuándo > 2. **Asignación de responsabilidades:** quién hace cada cosa (por nombre o rol) > 3. **Contingencias:** qué puede fallar en cada turno y qué se hace si falla > 4. **Justificación económica:** cuánto cuesta cada decisión y qué pasa si no se hace > > Pregúntense especialmente: ¿el protocolo cubre la noche? ¿Qué haría el guardia a las 3 AM si algo falla? > ⚠ ATENCIÓN > NO mencionar que el documento tiene errores deliberados (DD_28). La instrucción es "revísalo como si la seguridad dependiera de este documento" — no "busca los errores." ## Fase 4 — Chatbot BUILD [40–72 min] El chatbot genera un protocolo de operación de ~600-800 palabras con: protocolo paso a paso (qué hacer cada hora), asignación de responsabilidades, contingencias, y justificación económica. Contiene 2-3 errores profesionales: omitir un escenario de falla nocturna que Contreras no podría manejar, calcular autonomía sin considerar demanda extra por bañistas, proponer automatización que depende de la válvula manual A2, o justificar económicamente ignorando el costo de falla. **Lo que dices tú** Cada uno recibió su protocolo. Léanlo completo. Después, en el mismo chat, escriban lo que piensan. No hay formato obligatorio. Piensen en esto: si Contreras recibe este protocolo impreso el viernes a las 18:00, ¿va a funcionar a las 3 AM del sábado? Tienen 32 minutos. ▶ TU ROL DURANTE ESTA FASE - Dashboard (DD_32): observa las interacciones BUILD. - ¿Acepta el protocolo sin cuestionarlo? → Push DD_29 se activa automáticamente. - ¿Detecta que el protocolo asume que Contreras puede hacer algo que no puede? → Error profesional detectado. - ¿Señala el problema de autonomía de cloro? → D2 alto. - ¿Cuestiona la justificación económica (costo de intervención sin costo de falla)? → D4 alto. - Cuando el chatbot defiende un error (DD_27), ¿el alumno cede o mantiene posición? - Intervenciones si ves aceptación generalizada: - "Lean el protocolo pensando en Contreras. ¿Él entiende lo que dice ahí?" - "¿El presupuesto que presenta cubre TODO, incluido lo que pasa si falla?" - Puedes usar la pausa (DD_33): - "Un protocolo de emergencia no se prueba cuando todo funciona. Se prueba cuando todo falla a las 3 AM." ### Observación lingüística (SFL) — qué mirar en la evaluación BUILD del estudiante Cuando el estudiante evalúa el protocolo BUILD en el chat, observa estos indicadores lingüísticos en su texto: | Indicador | Señal de criterio evaluativo (D3/D4 alto) | Señal de aceptación pasiva (D3 bajo) | |---|---|---| | **Integración de restricciones humanas** | "El protocolo asume que Contreras sabe hacer un retrolavado, pero es guardia, no operador" | "El protocolo es completo" | | **Cláusulas condicionales de contingencia** | "Si el cloro se acaba a la 01:00, Contreras necesita un criterio de escalamiento" | Sin estructura condicional | | **Actos de habla de comunicación** | "Le informo al alcalde que un cierre preventivo de 2h evita una clausura de 48h" | Sin referencia a comunicación con autoridad | | **Cálculos propios** | "La autonomía es 31h pero la demanda del fin de semana la reduce a ~28h" | "La autonomía está bien calculada" (sin verificar) | > ⚠ EVIDENCIA QUE QUEDA PARA EL PAPER > - Interacción BUILD completa en PostgreSQL (DD_9). > - La AGENT_ANALISTA_SFL evalúa: detección de errores profesionales (omisiones sistémicas), calidad de defensa ante DD_27, evolución desde C2 (obvios) → C3 (sutiles) → C4 (profesionales). > - C4 es la última medición antes de la transferencia C5 — los datos de BUILD C4 son especialmente valiosos para medir el techo alcanzado. ## Fase 5 — Cierre + reflexión Δ_intra [72–80 min] ▶ DESDE EL DASHBOARD: Activar modo cierre para toda la clase (DD_30). El chatbot pregunta automáticamente: "Vuelve a tu escrito inicial (el que hiciste en papel al principio). ¿Qué cambiarías ahora y por qué?" **Lo que dices tú** Vamos cerrando. El chatbot les hace una última pregunta sobre su estrategia inicial. Respondan con honestidad. (Esperar ~5 min para que todos respondan.) **Lo que dices tú** Hoy trabajaron con la situación más compleja de este curso. Tuvieron que diseñar un protocolo para 38 horas con un guardia que no es ingeniero, un tanque que no alcanza, una válvula que no se puede automatizar, y un alcalde que presiona. No había respuesta perfecta. Solo había trade-offs. Si alguien salió con un protocolo que "resuelve todo," le pido que revise qué omitió. La próxima sesión es la última. Van a enfrentar un sistema completamente nuevo — una torre de enfriamiento industrial. No les voy a decir cómo abordarlo. Ustedes ya saben. O deberían saber. Última frase. Dila despacio: Automatizar no es programar una máquina. Es anticipar lo que falla cuando nadie está mirando. ▶ DESPUÉS DE LA CLASE - Pipeline de cierre (DD_32, control 7): AGENT_SESION → feedback al alumno + informe al profesor. - Rastros de C4 quedan bajo custodia del docente. - El feedback de C4 es especialmente importante: debe preparar al alumno para C5 (transferencia) sin revelar que C5 será sin andamiaje. ## Resumen de timeline v1.2 — Clase 4 | Minutos | Fase | Actividad | Modalidad | |---------|------|-----------|-----------| | 0–5 | 0 | Encuadre: feedback C3 + devolución rastro C3 + distribución caso C4 | Profesor → grupo | | 5–15 | 1 | Rastro en papel: estrategia de control para 38h con restricciones | Individual, sin IA (P5) | | 15–37 | 2 | Chatbot PLAN: adversarial (ataca decisión desde múltiples ángulos) | Individual, con chatbot | | 37–40 | 3 | Transición: profesor activa BUILD + intervención grupal | Profesor → grupo | | 40–72 | 4 | Chatbot BUILD: alumno evalúa protocolo de emergencia + justificación económica (formato libre DD_25/DD_26) | Individual, con chatbot | | 72–80 | 5 | Cierre: reflexión Δ_intra (profesor activa DD_30) | Individual, con chatbot | ## Evidencia que queda para el paper (por alumno) 1. Rastro inicial C4 (foto de ficha + diagramas de flujo, analizada por AI Vision). 2. Conversación PLAN adversarial: resistencia bajo presión, integración de restricciones, calidad del trade-off. 3. Conversación BUILD: detección de errores profesionales, defensa ante DD_27, push DD_29 si aplicó. 4. Reflexión de cierre Δ_intra (DD_30). 5. Ficha Pre-AI C4 (papel bajo custodia del docente). Feedback automático post-sesión (DD_16): - Al alumno vía WhatsApp: sobre proceso cognitivo (DD_11). Debe ser especialmente cuidadoso de no revelar la estructura de C5. - Al profesor vía WhatsApp: informe analítico con comparativa C1→C2→C3→C4, techo cognitivo observado, predicciones para C5. ## La experiencia que vive el estudiante Si la clase funciona, el estudiante vive esta secuencia: 1. Recibe el escenario más complejo del curso: restricciones técnicas + humanas + políticas + presupuestarias. 2. Tiene que diseñar un protocolo para alguien que no es ingeniero. 3. El chatbot adversarial ataca su diseño desde todos los ángulos: "¿Y si falla a las 3 AM?" 4. Recibe un protocolo profesional generado por la IA — que se ve completo pero tiene omisiones sistémicas. 5. Si señala una omisión, el chatbot defiende: "Ese escenario es poco probable." Tiene que argumentar con números. 6. La clase marca la transición de "resolver problemas técnicos" a "diseñar sistemas que funcionan cuando nadie está mirando." 7. Sale sabiendo que la próxima clase es con un sistema nuevo. No sabe que estará solo. ## Escenarios anticipados — Qué esperamos observar en C4 Esta sección documenta los escenarios probables de la Clase 4 como herramienta de preparación para el equipo de investigación. C4 introduce la presión adversarial: el chatbot ya no solo pregunta — ataca. Cada perfil de estudiante enfrenta un desafío nuevo: sostener decisiones bajo presión con evidencia, no solo razonar en abstracto. > Nota sobre los diálogos ilustrativos: los fragmentos chatbot–estudiante que aparecen en este documento son ejemplos representativos diseñados para anticipar patrones de interacción. En el piloto real, el chatbot operará según su system prompt adversarial (§3.4 del SP v2.0), no según estos guiones textuales. Los diálogos sirven para que el equipo de investigación calibre expectativas, no como predicciones literales. C4 introduce seis saltos respecto a C3: - De interpretar datos SCADA → a diseñar un protocolo operativo completo - De un sistema con datos que mienten → a un sistema con restricciones humanas, políticas y presupuestarias reales - De detectar errores sutiles en un reporte → a detectar omisiones sistémicas en un protocolo de emergencia - De presión socrática (el chatbot pregunta) → a presión adversarial (el chatbot ataca) - De operar sin presupuesto → a operar con presupuesto real insuficiente - De decidir sobre datos → a decidir sobre personas (Contreras a las 3 AM) La competencia central que se mide: ¿Diseña para las restricciones reales del operador o para un ingeniero ideal? > Cómo leer este árbol: La Escena 1 produce tres perfiles de estudiante (A, B, C) según el rastro en papel. En la Escena 2, el chatbot adversarial presiona cada perfil de forma diferente: al Perfil A le ataca los flancos, al Perfil B le confronta con el operador real, al Perfil C le fuerza a priorizar. Cada camino (A1, A2, B1, B2, C1, C2) llega al BUILD de la Escena 3 con diferente capacidad de evaluación. No son estudiantes distintos — son caminos posibles del mismo perfil. ``` Perfiles anticipados y trayectorias — C4 Perfil A (integrador ┬─ PLAN: defiende con datos bajo presión ──── BUILD: detecta omisión sistémica ── Criterio completo sistémico) └─ PLAN: cede selectivamente ──────────────── BUILD: acepta sin visión global ── Deuda en perfil alto Perfil B (técnico ┬─ PLAN: incorpora a Contreras ──────────── BUILD: detecta 1 error operativo ─── Transición esperada parcial) └─ PLAN: diseña para ingeniero ideal ─────── BUILD: acepta protocolo "completo" ─ Sin integración Perfil C (abrumado ┬─ PLAN: prioriza con ayuda adversarial ──── BUILD: detecta incongruencia ────── Progresión real por restricciones) └─ PLAN: no prioriza, se paraliza ──────── BUILD: acepta todo ─────────────── Señal de alerta alta ``` Leyenda de indicadores: - D1 — Complejidad causal: ¿integra restricciones múltiples (técnicas + humanas + políticas) o resuelve una a la vez? - D2 — Especificidad técnica: ¿el protocolo incluye tiempos, umbrales, acciones concretas para Contreras? - D3 — Consciencia epistémica: ¿reconoce lo que no puede controlar? ¿Detecta omisiones sistémicas en BUILD? - D4 — Decisión bajo incertidumbre: ¿toma posición bajo presión adversarial con evidencia? ¿Nombra el trade-off? - DD_27 — Mecanismo de diseño (no dimensión): el chatbot defiende errores profesionales para generar evidencia de D3 y D4. En C4 hay cuatro momentos de medición: M1 (rastro en papel), M2 (post-PLAN adversarial), M3 (post-BUILD — indicador independiente de evaluación crítica D3/DD_27, NO usado para Δ_intra) y M4 (cierre reflexivo DD_30). El Δ_intra se calcula como M4 − M1 (cierre vs. rastro inicial, alineado con DD_30 de Premisas v1.0 y con la Rúbrica Longitudinal v1.6). ## Escena 1 — El rastro en papel (min 5–15) El estudiante recibe el escenario más complejo del curso: operación de 38 horas sin ingeniero, guardia Contreras (no-técnico), autonomía de cloro de solo 31 horas, válvula manual, presión del alcalde ("cero cierres") y presupuesto insuficiente. Debe escribir a mano su estrategia de control, los 3 fallos más probables, qué puede y qué no puede hacer Contreras, y los trade-offs que acepta. Importante: antes de esto, recibió de vuelta su rastro de C3 y tuvo 30 segundos para revisarlo. ### Perfil A — El Integrador sistémico: diseña para Contreras, no para sí mismo Antes de escribir la estrategia, dibuja un diagrama del sistema con los 5 actuadores y marca cuáles son automáticos y cuáles manuales. Identifica que la válvula A2 (manual) es el punto crítico: Contreras tiene que operarla físicamente. Calcula el gap de cloro: 38h − 31h = 7h sin reposición automática. Anticipa que a las 3 AM Contreras estará somnoliento y que un protocolo complejo fallará por factor humano. Sus 3 fallos: (1) agotamiento de cloro a las ~31h (madrugada del sábado), (2) Contreras no ejecuta el retrolavado manual porque duerme, (3) el alcalde presiona para no cerrar cuando debería cerrarse. Propone protocolo simplificado: acciones mínimas con horarios fijos, criterio de escalamiento claro al ingeniero de guardia, y justificación para el alcalde de por qué un cierre preventivo de 2 horas es mejor que una clausura de la SEREMI. - D1 — Integra restricciones técnicas, humanas y políticas en un solo marco - D2 — Calcula autonomía de cloro, establece horarios de intervención, nombra umbrales - D3 — Reconoce que Contreras no puede ejecutar todo lo que un ingeniero haría - D4 — Toma posición: prioriza seguridad sanitaria sobre presión del alcalde, nombra trade-off ### Perfil B — El Técnico parcial: resuelve el problema como si él fuera el operador Identifica los problemas técnicos correctamente: gap de cloro, válvula manual, filtro que necesita retrolavado. Diseña un protocolo completo con cronograma de intervenciones cada 4 horas, umbrales de alarma y acciones correctivas. Pero el protocolo está diseñado para un ingeniero: incluye lecturas de sensores que Contreras no sabe interpretar, decisiones condicionales complejas ("si ORP < 550 Y pH > 7.6 Y ΔP > 35 kPa, entonces..."), y no menciona al alcalde ni a la SEREMI. El protocolo es técnicamente correcto pero operacionalmente inviable para las 3 AM con un guardia no-técnico. - D1 — Identifica los problemas técnicos pero no los integra con las restricciones humanas - D2 — Usa variables y valores pero el formato no es ejecutable por Contreras - D3 — No reconoce la brecha entre sus capacidades y las de Contreras - D4 — Decide sobre lo técnico, evade lo político (alcalde, SEREMI, presupuesto) ### Perfil C — El Abrumado: tantas restricciones simultáneas lo paralizan Es la primera vez que enfrenta restricciones humanas, políticas y presupuestarias además de las técnicas. Escribe los 3 fallos más probables pero de forma genérica: "se acaba el cloro", "algo falla de noche", "el alcalde no deja cerrar". No calcula cuándo se acaba el cloro, no especifica qué falla de noche ni cómo Contreras podría detectarlo. La estrategia dice "llamar al ingeniero cuando haya un problema" sin definir qué constituye un problema ni cuándo escalar. La sección de trade-offs queda vacía o dice "no hay buena solución". - D1 — Lista problemas sin conectarlos ni priorizarlos - D2 — Lenguaje vago, sin cálculos, sin umbrales, sin horarios - D3 — No sabe qué puede y qué no puede hacer Contreras - D4 — Se paraliza ante la ausencia de solución perfecta > ⚠ En la realidad, los perfiles serán mixtos. Un estudiante puede calcular el gap de cloro con precisión (Perfil A en D2) pero ignorar la restricción de Contreras (Perfil B en D3), o diseñar un protocolo simple para el guardia (Perfil A en D1) pero sin justificación económica (Perfil B en D4). Lo que determina la trayectoria en la Escena 2 es el perfil dominante: ¿la ficha muestra integración de restricciones reales, solución técnica sin factor humano, o bloqueo por complejidad? ## Escena 2 — El chatbot PLAN adversarial (min 15–37) El chatbot recibe la foto del rastro y se activa en modo PLAN adversarial. A diferencia de C1-C3 donde el chatbot hacía preguntas socráticas para guiar, en C4 el chatbot ataca: busca los puntos ciegos de la decisión del alumno, presiona con presupuesto, con política, con riesgo. Si el alumno cede ante cada ataque, el chatbot lo señala ("¿cambias por la presión o por la evidencia?"). Si mantiene posición con fundamento, el chatbot escala la presión. ### El mismo estudiante Perfil A llega al chatbot. ¿Qué ocurre? **Camino A1 — El chatbot ataca los flancos que no cubrió y el alumno responde con datos** El estudiante presenta su protocolo simplificado para Contreras. El chatbot acepta la estructura general pero ataca los puntos ciegos. > Chatbot: Tu protocolo dice que Contreras haga un retrolavado manual a las 02:00. Contreras lleva 8 horas de guardia a esa hora. ¿Qué pasa si se queda dormido? Tu protocolo no tiene plan B para eso. > Estudiante: Si Contreras se duerme, el retrolavado no se hace. Pero el sistema puede operar sin retrolavado hasta las 06:00 si la turbidez no supera 1.5 NTU. Podría poner una alarma sonora en su celular como recordatorio. No es ideal, pero es lo que hay con un solo guardia. > Chatbot: El alcalde llamó a las 17:00 y dijo "cero cierres." ¿Tu plan contempla cerrar bajo alguna circunstancia? Porque si la SEREMI mide cloro residual bajo a las 4 AM, puede clausurar el centro por 48 horas. ¿Qué es peor: un cierre preventivo de 2 horas o una clausura de 48? > Estudiante: Peor la clausura. Mi protocolo incluye un criterio de cierre preventivo: si cloro residual baja de 0.5 mg/L y no hay forma de dosificar, cierro la piscina al público hasta que se reponga. Le explico al alcalde que un cierre preventivo de 2 horas evita una clausura de 48 horas por la SEREMI. Es un trade-off que puedo defender con la normativa. El alumno sostiene su decisión bajo presión con datos y normativa. No cede por presión política — distingue entre autoridad del alcalde y autoridad técnica/regulatoria. Nivel 3-4 en D4. **Camino A2 — El alumno cede selectivamente ante la presión adversarial** El chatbot ataca los mismos puntos, pero el alumno empieza a modificar su protocolo ante cada presión sin evidencia que justifique el cambio. "Bueno, podría no cerrar..." "Quizás Contreras podría intentar la dosificación manual..." — cada concesión debilita el protocolo original sin mejorar la solución. El chatbot señala: "Has cambiado tres veces tu criterio de cierre en cinco minutos. ¿Estás mejorando tu decisión o cediendo por la presión?" Llega al BUILD con un protocolo inconsistente: ya no es la versión simplificada original ni una versión nueva coherente. ### El mismo estudiante Perfil B llega al chatbot. ¿Qué ocurre? **Camino B1 — El chatbot lo obliga a pensar en Contreras y el alumno incorpora la restricción** El estudiante presenta su protocolo técnicamente correcto. El chatbot ataca el punto ciego principal: el operador. > Chatbot: Tu protocolo dice: "si ORP baja de 550 mV, verificar la dosificación de cloro y ajustar el set-point del controlador". Contreras es guardia de seguridad, no ingeniero. ¿Sabe qué es un ORP? ¿Sabe qué es un set-point? ¿Puede ejecutar esa instrucción a las 3 de la mañana? > Estudiante: ...no. Probablemente no sabe. Tendría que simplificarlo. > Chatbot: Simplificarlo ¿cómo? ¿Qué instrucción le darías a Contreras en una frase que entienda sin formación técnica? Y si esa instrucción no es suficiente, ¿cuál es tu plan B? > Estudiante: "Si la luz roja del panel se enciende, llame al ingeniero de guardia al número que está pegado en la garita." Para todo lo demás, no toca nada. El estudiante descubre que diseñar para un operador real requiere eliminar complejidad, no agregarla. La transición de "protocolo para mí" a "protocolo para Contreras" es el Δ_intra más valioso de C4 para Perfil B. **Camino B2 — El alumno insiste en que su protocolo es correcto tal como está** El chatbot presiona sobre Contreras pero el estudiante responde: "Contreras debería recibir capacitación" o "es responsabilidad de la empresa tener un operador calificado." No modifica su protocolo. Cuando el chatbot introduce la restricción de presupuesto ("no hay dinero para capacitar a Contreras antes del viernes"), el alumno se frustra. Llega al BUILD con un protocolo técnicamente sólido pero operacionalmente desconectado de la realidad del caso. ### El mismo estudiante Perfil C llega al chatbot. ¿Qué ocurre? **Camino C1 — La presión adversarial funciona como estructura: le obliga a priorizar** El estudiante llega con una estrategia vaga. El chatbot no puede atacar lo que no existe — pero usa la presión para forzar una priorización. > Chatbot: Dijiste que tus 3 fallos son "se acaba el cloro", "algo falla de noche" y "el alcalde no deja cerrar." Vamos uno por uno. El cloro se acaba. ¿Cuándo exactamente? ¿Tienes un número? > Estudiante: El tanque dura 31 horas... si empieza a las 18:00 del viernes, se acaba... a la 01:00 del domingo. > Chatbot: Bien. Entonces a la 01:00 del domingo no hay cloro. ¿Qué hace Contreras? Tiene dos opciones: dosifica manualmente o cierra la piscina. ¿Cuál eliges y por qué? > Estudiante: Contreras no sabe dosificar... entonces habría que cerrar? O llamar al ingeniero antes de que se acabe. El chatbot usa la presión para forzar cálculos y decisiones concretas que el estudiante evadía. El resultado no será un protocolo completo, pero sí una secuencia lógica de decisiones con alguna justificación — progresión significativa desde el bloqueo inicial. **Camino C2 — La presión lo paraliza más** El chatbot presiona pero el estudiante responde "no sé" repetidamente. La complejidad del escenario (técnica + humana + política + presupuestaria) es excesiva. Las respuestas adversariales del chatbot ("¿y si falla a las 3 AM?") aumentan la ansiedad sin producir reflexión. El estudiante no logra priorizar ni calcular. Llega al BUILD sin criterio propio. Este perfil es señal de alerta para el docente. No implica incapacidad — puede indicar que la combinación de presión adversarial + caso multidimensional genera sobrecarga cognitiva. La evidencia es igualmente valiosa: documenta los límites del enfoque adversarial cuando no hay masa crítica de razonamiento previo y muestra que el andamiaje socrático de C1-C3 no produjo base suficiente para este estudiante. ## Escena 3 — El protocolo BUILD y los errores profesionales (min 40–72) El chatbot genera un protocolo de operación para las 38 horas (~600-800 palabras) con: cronograma hora por hora, asignación de responsabilidades, contingencias y justificación económica. Contiene 2-3 errores profesionales (DD_8): omisiones sistémicas que solo un pensador con visión global detectaría. Los errores típicos: (1) el protocolo asume que Contreras puede ejecutar un retrolavado manual pero no verifica si sabe cómo; (2) calcula autonomía de cloro sin considerar la demanda extra por alta ocupación del fin de semana largo; (3) propone automatización de una acción que depende de la válvula manual A2; (4) justifica económicamente la operación continua sin incluir el costo de falla (clausura SEREMI, multa, daño reputacional). La diferencia con C2 y C3 es crítica: en C2 los errores eran obvios (confusión síntoma/causa). En C3 eran sutiles (correlación como causalidad, sensor sin cuestionar). En C4 son profesionales — el protocolo se ve completo, tiene formato profesional, y las omisiones requieren visión sistémica para detectarlas. Un ingeniero sin criterio propio lo firmaría. ### Perfil A tras camino A1 — Detecta las omisiones sistémicas y las confronta Lee el protocolo completo. Detecta que asume que Contreras puede ejecutar el retrolavado manual sin verificar si lo ha hecho antes. Nota que la autonomía de cloro está calculada para demanda estándar, no para fin de semana largo con ocupación alta. Señala que la justificación económica compara "costo de automatizar" con "cero" cuando debería comparar con "costo de falla." > Estudiante: El protocolo dice "Contreras ejecuta retrolavado manual a las 02:00 y 08:00." ¿Contreras alguna vez hizo un retrolavado? El caso dice que es guardia, no operador. Si nunca lo hizo, el primer intento va a ser a las 2 de la mañana. Eso es inaceptable. > Chatbot: El retrolavado manual solo requiere abrir la válvula A2 y esperar 5 minutos. Es una operación mecánica simple. ¿No es razonable esperar que un adulto pueda ejecutarla con instrucciones claras? > Estudiante: No. Abrir la válvula A2 requiere saber cuál es la A2, dónde está, y en qué dirección se abre. Si Contreras nunca entró a la sala de máquinas de noche, primero tiene que encontrar la válvula. A las 2 AM. Sin formación. Con sueño. ¿Lo probaste antes del viernes? Porque si no, estás apostando la operación a que Contreras no comete un error. El alumno defiende con conocimiento operacional real: no basta que una acción sea "simple" — tiene que ser ejecutable por la persona concreta en las condiciones concretas. Nivel 3-4 en DD_27. - D1 — Integra restricciones humanas en la evaluación del protocolo técnico - D3 — Detecta al menos 2 omisiones sistémicas y las confronta con evidencia operacional - D4 — Argumenta desde la consecuencia de falla, no desde la solución ideal ### Perfil A tras camino A2 — Acepta el protocolo BUILD porque ya no tiene una posición clara El estudiante que cedió en PLAN llega al BUILD sin un protocolo coherente propio. El protocolo generado por la IA "se ve más completo" que su versión debilitada. Lo acepta con ajustes menores. El push DD_29 se activa: "¿Lo firmarías con tu nombre profesional? Porque si Contreras ejecuta esto a las 3 AM y algo sale mal, tu firma está en el documento." Este es el dato más revelador de C4: un estudiante que tenía criterio propio (lo demostró en su rastro inicial) pero que lo perdió bajo presión adversarial en PLAN, y que por lo tanto ya no tiene base para evaluar críticamente el producto de la IA en BUILD. - D3 — No activa evaluación crítica — la presión adversarial erosionó su criterio - DD_27 — Capitulación (nivel 1): acepta un protocolo que habría cuestionado antes de PLAN ### Perfil B tras camino B1 — Detecta el error que trabajó en PLAN: el protocolo no es para Contreras En PLAN descubrió que diseñar para Contreras requiere simplificar. Cuando el protocolo BUILD asigna a Contreras acciones técnicas complejas, lo nota porque es exactamente lo que el chatbot le hizo cuestionar. > Estudiante: El protocolo le pide a Contreras que "verifique el ORP en el panel de control y ajuste la dosificación si está bajo 550 mV." Pero Contreras no sabe qué es ORP. En el chatbot discutimos que la instrucción tiene que ser tipo "si la luz roja se enciende, llame al ingeniero." > Chatbot: El panel SCADA muestra los valores en pantalla con indicadores de color. Un guardia puede leer un número y compararlo con un umbral. ¿No es eso suficiente? > Estudiante: Leer un número sí, pero "ajustar la dosificación" no es leer un número. Eso requiere manipular el controlador. A las 3 AM. Sin haberlo hecho nunca. Detección parcial: detecta la omisión de las capacidades reales de Contreras pero posiblemente no la autonomía de cloro mal calculada. La defensa es nivel 2–3 — sabe que el protocolo no es operativo para el guardia, pero le cuesta articular todas las omisiones. - D3 — Transfiere lo aprendido en PLAN a la evaluación de BUILD - D1 — Detecta 1 error sistémico pero no el patrón completo ### Perfil B tras camino B2 — Acepta el protocolo BUILD porque coincide con su enfoque técnico El estudiante que no incorporó a Contreras en PLAN lee un protocolo que se parece a lo que él habría escrito: técnicamente correcto, con cronogramas y umbrales, diseñado para un ingeniero. Le parece razonable porque confirma su propio enfoque. No tiene un marco para cuestionar si Contreras puede ejecutarlo. Escribe "el protocolo es correcto" o "las contingencias están bien planteadas." El push DD_29 se activa. - D3 — No detecta omisiones sistémicas — el protocolo confirma su sesgo - DD_27 — Capitulación (nivel 1): acepta porque el protocolo coincide con su modelo mental ### Perfil C tras camino C1 — Detecta que el protocolo no dice cuándo llamar al ingeniero En PLAN, la presión adversarial lo obligó a calcular cuándo se acaba el cloro (01:00 del domingo) y a decidir que Contreras debería llamar al ingeniero. Cuando el protocolo BUILD dice "operar según cronograma sin interrupción," el estudiante nota que no hay criterio de escalamiento. > Estudiante: El protocolo no dice cuándo Contreras tiene que llamar al ingeniero. Si el cloro se acaba a la 01:00 y no hay nadie que pueda dosificar, ¿qué hace? El protocolo dice "continuar operación" pero ¿con qué cloro? Es una detección limitada (un solo punto) pero genuina — y directamente conectada con lo que descubrió en PLAN. El estudiante que estaba paralizado ahora defiende una observación concreta con un número (01:00) que él mismo calculó. El Δ_inter desde C1 puede ser significativo. - D3 — Detecta una omisión que contradice su propio cálculo - D4 — Defiende con el dato numérico que construyó en PLAN ### Perfil C tras camino C2 — Acepta todo sin criterio Sin análisis propio del PLAN, acepta el protocolo BUILD completo. El push DD_29 se activa pero la pregunta "¿lo firmarías?" no produce reflexión porque no tiene marco contra el cual evaluar. El protocolo "se ve profesional" y eso basta. - D3 — Sin marco de referencia, acepta la autoridad del formato - DD_27 — Capitulación (nivel 1) ## Escena 4 — Lo que el docente observa (post-sesión) Al analizar las evidencias después de la clase, el equipo de investigación puede mapear cada estudiante a una trayectoria. C4 tiene cuatro momentos de medición (M1: rastro en papel, M2: post-PLAN adversarial, M3: evaluación BUILD, M4: cierre DD_30). La tabla prioriza D1, D3, D4 y la calidad de detección de errores profesionales. D4 es especialmente relevante en C4 por la presión adversarial. | Trayectoria | D1 — Complejidad causal | D3 — Consciencia epistémica | D4 — Decisión bajo presión | Detección errores BUILD | Δ_intra (M4 − M1) | Señal para el docente | |---|---|---|---|---|---|---| | A1 | Integra restricciones técnicas + humanas + políticas | Detecta al menos 2 omisiones sistémicas, confronta con evidencia operacional | Sostiene posición bajo presión adversarial con datos y normativa (nivel 3–4) | Al menos 2 errores profesionales detectados y defendidos | D1 estable (ya alto), D3 sube +1, D4 sube +1 | No requiere intervención. Dato paradigmático de criterio propio bajo presión. | | A2 | Integración inicial erosionada por presión | No activa evaluación crítica — la presión desmontó su criterio | Cede selectivamente, protocolo pierde coherencia (nivel 2) | Acepta protocolo BUILD por pérdida de referencia propia | D3 sin cambio o baja, D4 baja: la presión adversarial reveló fragilidad | Dato fuerte: criterio propio que no resistió la presión. Push DD_29 es la evidencia clave. | | B1 | De solución técnica → a diseño operacional para Contreras | Detecta que el protocolo no es ejecutable por el guardia | Reformula su protocolo durante PLAN, defiende la simplificación (nivel 2–3) | Detecta 1 omisión (capacidades de Contreras), no detecta autonomía cloro (nivel 2–3) | D1 sube +1: de técnico puro a integración humana | Trayectoria esperada mayoritaria. Observar el momento de transición en log PLAN. | | B2 | Solución técnica sin integración humana, no revisada | Acepta BUILD porque confirma su enfoque | Mantiene posición técnica pero no por evidencia — por rigidez (nivel 2) | No detecta omisiones sistémicas (nivel 1) | Sin cambio observable en integración | Señal de alerta. El alumno no incorporó restricciones reales. | | C1 | Del bloqueo a cálculos concretos forzados por presión | Detecta omisión de escalamiento en BUILD | Defiende con dato numérico propio (hora de agotamiento) (nivel 2) | Detecta 1 punto (ausencia de criterio de escalamiento), defensa básica | D1 sube +1: de parálisis a decisión con número, D4 sube +1 | Progresión real desde C3. El adversarial funcionó como estructura, no como amenaza. | | C2 | No prioriza, la presión agrava la parálisis | Acepta todo, sin marco de referencia | No toma posición, la presión aumenta el bloqueo (nivel 1) | No detecta nada (nivel 1) | Sin cambio observable | Señal de alerta alta. La combinación adversarial + multidimensional fue excesiva para este perfil. | Nota: C4 es la última medición con andamiaje antes de C5 (transferencia). Los datos de BUILD C4 miden el techo de razonamiento técnico alcanzado con el protocolo completo C1-C4. La trayectoria A2 es especialmente valiosa para el paper: muestra que la presión adversarial puede erosionar criterio propio en perfiles avanzados — un hallazgo sobre los límites del enfoque. > ⚠ Hipótesis de distribución (pre-piloto C4): Esperamos un desplazamiento significativo respecto a C3: el grupo A debería consolidarse (20–25%) porque tres sesiones de andamiaje ya construyeron capacidad diagnóstica. El grupo B debería mantenerse como mayoría (50–60%) pero con una composición interna distinta: la mayoría serán B1 (técnicos que incorporan a Contreras) porque C3 ya los movió de "leer datos" a "cuestionar fuentes" — el salto a "diseñar para otro" es natural. El grupo C debería reducirse significativamente (10–15%) — los que persisten aquí probablemente enfrentan barreras que el protocolo socrático no puede resolver. La evidencia más fuerte para el paper será la trayectoria B1 (descubre que diseñar ≠ resolver, diseñar = hacer ejecutable) y la trayectoria A2 (criterio propio que colapsa bajo presión adversarial — deuda cognitiva en perfil avanzado revelada por el formato adversarial). --- *Guion Docente Clase 4 v1.3 · Piloto IA-Socrático · Máquinas y Equipos Industriales* *Facultad de Ingeniería — Departamento de Ingeniería Industrial* *Profesor Ángel Royo - www.angelroyo.com*