--- nombre: Protocolo Clase 4 v1.1 tipo: doc_pro clase: 4 version: 1.1 fecha_emision: 2026-05-24 status: fuente_normativa emitido_por: Ángel Royo Melgarejo (IP) referencia_premisas: instrumentos/doc_inv_Premisas_Diseno_v1.1.md referencia_guion: instrumentos/clase4/doc_pro_GuionDocente_Clase4_v1.3.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) nota: "v1.1 reestructura Markdown al arquetipo aprobado de C1 (tablas reales, encabezados #, listas con -). Contenido v1.0 preservado íntegramente." --- # Protocolo de Investigación Docente — 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) | | Sesión | Clase 4 de 5 | | Título | Controlar un sistema técnico: automatización, personas y trade-offs bajo presión | | Modalidad | Laboratorio presencial — trabajo individual (P6) | | Duración estimada | 80 minutos (P4) | | Rol del tutor socrático | Comité de crisis sobre la decisión (min 15–37) + revisión profesional de protocolo de emergencia imperfecto (min 40–72). El profesor controla la transición interna desde su interfaz (DD_19). | | Versión del protocolo | v1.1 — Mayo 2026 (reestructura Markdown al arquetipo C1; contenido v1.0 preservado) | ### Nota sobre esta versión La v1.1 no modifica el contenido metodológico de la v1.0. Únicamente reestructura el Markdown para alinearse con el arquetipo aprobado del Protocolo C1 v1.2: encabezados con `#`, tablas Markdown reales, listas con guiones y notas en bloques `>`. Esto garantiza que Pandoc + XeLaTeX generen un PDF con la misma jerarquía tipográfica, tablas `booktabs` y pie de página institucional que el Protocolo C1. --- ## 0. Principio de puesta en escena pedagógica La Clase 4 se ejecuta como decisión profesional bajo presión, no como modo adversarial. La escena es un comité de crisis: operación, mantenimiento, seguridad y gerencia cuestionan una solución que debe funcionar durante 38 horas sin ingeniero. La IA intensifica el dilema, pero no es el protagonista. El foco está en si el protocolo funciona a las 3 AM con Contreras solo, válvulas manuales, autonomía limitada y presión política. --- ## 1. Encuadre investigativo ### 1.1 Problema de investigación La decisión técnica en contexto real no es solo técnica: está condicionada por presupuesto, personas, tiempo, riesgo político y la capacidad real de quienes operan el sistema. La IA generativa puede producir protocolos de operación impecables en formato pero con omisiones que solo detecta quien tiene visión sistémica: condiciones de emergencia no cubiertas, redundancias contradictorias, procedimientos imposibles para el operador real. ### 1.2 Pregunta de investigación ¿Cómo cambia la calidad del razonamiento técnico de los estudiantes cuando se les exige producir pensamiento propio antes de interactuar con un chatbot socrático y defender posteriormente una decisión técnica? ### 1.3 Hipótesis pedagógica El uso de un chatbot socrático, combinado con rastro inicial visible y transferencia final a un caso nuevo, puede fortalecer la evidencia de razonamiento técnico en vez de sustituirlo. ### 1.4 Unidad de análisis La trayectoria de razonamiento del estudiante a lo largo de las cinco sesiones. ### 1.5 Función específica de esta sesión en el diseño del piloto La Clase 4 cumple cuatro funciones simultáneas: - **Función pedagógica:** integrar razonamiento técnico, restricciones operativas, factores humanos y análisis de riesgo en una decisión defendible bajo presión. - **Función de máxima presión socrática:** el chatbot opera en modo adversarial — ataca la decisión del alumno desde evidencia, riesgo, alternativas, consecuencias de segundo orden, presión política y restricciones presupuestarias. - **Función de máximo escalamiento de errores:** el BUILD genera un protocolo con errores profesionales (DD_8) — omisiones de segundo orden que solo detecta quien tiene visión sistémica completa. - **Función de preparación para transferencia:** C4 es la última sesión con andamiaje socrático. C5 retirará todo el andamiaje y medirá qué queda. --- ## 2. Propósitos de la sesión ### 2.1 Propósito pedagógico Que el estudiante (a) diseñe un protocolo de operación para 38 horas continuas con un guardia no-técnico (Contreras), (b) gestione trade-offs reales entre seguridad, costo y viabilidad operativa, (c) evalúe críticamente un protocolo generado por IA detectando omisiones profesionales, (d) defienda decisiones bajo presión adversarial. ### 2.2 Propósito investigativo Capturar evidencia de: (a) capacidad de integración de múltiples restricciones antes de la mediación de IA; (b) resistencia argumentativa bajo presión adversarial máxima; (c) detección de errores de nivel profesional en un documento generado por IA. ### 2.3 Pregunta guía para el estudiante ¿Cómo opera este sistema durante 38 horas con un guardia que no es ingeniero, mejoras postergadas por presupuesto y un alcalde que llama? --- ## 3. Descripción del caso ### 3.1 Contexto operacional Centro Acuático Municipal de Maipú. Fin de semana largo: 38 horas de operación continua sin ingeniero de turno. El guardia Contreras sabe abrir y cerrar la válvula A2 (manual) pero no interpreta datos SCADA ni toma decisiones de dosificación. La autonomía de cloro es de 31 horas. El alcalde exige que las piscinas abran sí o sí. Las mejoras críticas (válvula automática, tanque mayor, operador de fin de semana) están postergadas por presupuesto (ver tabla de restricciones en caso técnico C4). ### 3.2 Criterio de diseño del caso El caso está diseñado para que no exista una solución perfecta. Todo protocolo viable requiere trade-offs explícitos: la seguridad total es inalcanzable con los recursos disponibles. El estudiante que intenta resolver todo simultáneamente se paraliza; el que prioriza con criterio produce un protocolo imperfecto pero defendible. La presión del alcalde introduce una restricción no-técnica que complica la decisión. ### 3.3 Material entregado al estudiante - Caso Técnico C4: restricciones operativas, 5 actuadores (A1-A5), tabla FMEA, restricciones presupuestarias, perfil de Contreras (n1). - Ficha Pre-AI C4: formulario de análisis con secciones para priorización de riesgos, protocolo preliminar, trade-offs, decisión bajo restricciones (n2). - Guía Chatbot C4: instrucciones para interactuar con el chatbot (n3). > **Condición de rastro inicial (minutos 5–15):** Sin internet, sin IA, sin consulta entre pares. Se permite: caso impreso, ficha, apuntes propios. --- ## 4. Instrucciones al estudiante para el rastro inicial Entregadas en la Ficha Pre-AI C4 (n2): **Paso 1 — Análisis de restricciones:** ¿cuáles son las restricciones duras (no negociables) y cuáles son flexibles? **Paso 2 — Priorización de riesgos:** ¿qué puede fallar? ¿qué consecuencia tiene cada falla? ¿cuál es la más grave? **Paso 3 — Protocolo preliminar:** diseña un protocolo de operación para Contreras. ¿Qué debe hacer, cuándo, y cómo sabe si algo va mal? **Paso 4 — Trade-offs:** ¿qué estás sacrificando? ¿qué riesgo estás aceptando conscientemente? **Paso 5 — Decisión bajo presión:** el alcalde llama a las 2 AM. ¿Qué le dices? ¿Con qué datos? Tiempo: 10 minutos. Trabajo individual. --- ## 5. Rol del chatbot en esta sesión ### Distribución temporal del chatbot en Clase 4 | Minutos | Estado del chatbot | Descripción | |---------|-------------------|-------------| | 0–5 | NO activo | Encuadre docente. | | 5–15 | NO activo | Rastro en papel. | | 15–37 | PLAN adversarial | Ataca la decisión del alumno desde múltiples ángulos: ¿qué pasa si Contreras se duerme? ¿y si el cloro se acaba a las 4 AM? ¿tu protocolo funciona a las 3 AM con un guardia asustado? ¿cuánto cuesta tu plan? ¿el municipio puede pagarlo este trimestre? Introduce restricciones nuevas mid-análisis. Fuerza trade-offs explícitos. | | 37–40 | Transición | Profesor activa BUILD desde Dashboard (DD_19) + intervención grupal. | | 40–72 | BUILD | El chatbot genera un protocolo de emergencia con errores profesionales (DD_8): omite la condición de parada de emergencia nocturna, propone redundancias contradictorias, incluye procedimientos que Contreras no puede ejecutar, FMEA incompleto. Defiende errores con argumentos técnicamente plausibles (DD_27). DD_28 protegido. | | 72–80 | Cierre | Chatbot pregunta Δ_intra (DD_30). | --- ## 6. Secuencia docente — Guion de sesión Duración total: 80 minutos (P4). Modelo de 6 fases (DD_24). | Tiempo | Fase | Acción del docente | Acción del estudiante | |--------|------|--------------------|-----------------------| | 0–5 min | Fase 0 — Encuadre + devolución | Devuelve rastro de C3. Contextualiza C4: "Hoy no van a analizar datos. Van a tomar decisiones que afectan personas." | Lee rastro C3. Recibe caso C4. | | 5–15 min | Fase 1 — Rastro en papel | Distribuye Ficha Pre-AI C4. Supervisa silenciosamente. | Analiza restricciones, prioriza riesgos, diseña protocolo preliminar. Sube foto (DD_38). | | 15–37 min | Fase 2 — PLAN adversarial | Observa vía dashboard. No interviene. | Defiende su protocolo ante un chatbot que ataca desde todos los ángulos. | | 37–40 min | Fase 3 — Transición | Activa BUILD (DD_19). "La IA va a generar un protocolo de emergencia. Si ustedes fueran el ingeniero que se va el viernes, ¿firmarían ese protocolo?" | Escucha instrucción. | | 40–72 min | Fase 4 — BUILD con errores profesionales | Observa quién detecta las omisiones sistémicas y quién acepta el protocolo. | Lee protocolo generado. Evalúa en formato libre (DD_25/DD_26). Chatbot defiende errores. | | 72–80 min | Fase 5 — Cierre + Δ_intra | Distribuye Ficha PostAI C4 (n4). Recoge materiales. | Reflexión final. Δ_intra (DD_30). | --- ## 7. Entregables del estudiante Cinco entregables por estudiante: - **Rastro inicial C4** (análisis de restricciones, protocolo, trade-offs) — foto subida a plataforma. - **Registro de interacción PLAN adversarial** — logs PostgreSQL. - **Evaluación crítica del protocolo BUILD** — formato libre en el chat (DD_25/DD_26). - **Ficha PostAI C4** — reflexión metacognitiva (n4). - **Comparación Δ_intra** — qué cambió entre el protocolo inicial y el final (DD_30). --- ## 8. Matriz de evidencias para el paper | Evidencia | Qué revela para el paper | Cómo se registra | Dimensión de análisis | |-----------|--------------------------|-------------------|-----------------------| | Priorización de riesgos (rastro) | ¿Identifica riesgos sistémicos o solo riesgos técnicos aislados? ¿Considera el factor humano? | Foto + Ficha Pre-AI | D1 — Complejidad causal | | Protocolo para Contreras | ¿El protocolo es ejecutable por un guardia no-técnico? ¿Incluye contingencias? | Ficha Pre-AI C4 | D2 — Especificidad técnica, D4 | | Trade-offs explícitos | ¿Nombra lo que sacrifica? ¿Acepta riesgo conscientemente o lo ignora? | Ficha Pre-AI C4 | D4 — Decisión bajo incertidumbre | | Resistencia adversarial | ¿Mantiene su posición con argumentos o cede ante la presión? ¿Modifica con criterio o por miedo? | Logs PLAN (PostgreSQL) | D1, D3, D4 | | Detección de errores profesionales | ¿Detecta omisiones de segundo orden? ¿Identifica procedimientos inviables para Contreras? | Chat (formato libre) | D1, D2, D3 | | Aceptación pasiva (DD_29) | ¿Firmaría el protocolo generado sin revisarlo? Indicador de confianza acrítica. | Dashboard + logs | D3 | | Comparación Δ_intra | Evolución del protocolo: ¿mejoró, empeoró, o cambió de enfoque tras el contraste? | Ficha PostAI C4 | D3, D4 | --- ## 9. Criterios de análisis para el investigador | Cód. | Dimensión | Descripción operacional | Aplica también en | |------|-----------|------------------------|-------------------| | D1 | Complejidad causal | ¿Integra múltiples restricciones o resuelve una a la vez? ¿Considera consecuencias de segundo orden? | Clases 1, 2, 3, 5 | | D2 | Especificidad técnica | ¿El protocolo es operacional? ¿Incluye tiempos, umbrales, acciones concretas para Contreras? | Clases 1, 2, 3, 5 | | D3 | Consciencia epistémica | ¿Reconoce lo que no puede controlar? ¿Distingue lo que automatiza de lo que delega a Contreras? | Clases 1, 2, 3, 5 | | D4 | Decisión bajo incertidumbre | ¿Toma posición bajo presión o se paraliza? ¿Nombra el trade-off? ¿Responde al alcalde? | Clases 1, 2, 5 | --- ## 10. Nota metodológica para el paper La Clase 4 es la sesión de máxima presión del piloto en tres dimensiones simultáneas: presión socrática (modo adversarial), complejidad del caso (múltiples restricciones no-técnicas), y nivel de error en el BUILD (profesional — DD_8 máximo). El modo adversarial del chatbot no busca frustrar sino forzar la articulación explícita de trade-offs. En la práctica profesional, un ingeniero que presenta un protocolo de operación será cuestionado por su jefe, por el cliente, por el regulador y por el operador. La presión adversarial simula esa realidad. Los errores profesionales del BUILD C4 son el escalón final: después de errores obvios (C2) y sutiles (C3), el estudiante enfrenta omisiones que parecen correctas pero que tienen consecuencias operativas graves — un protocolo que Contreras no puede ejecutar, una condición de emergencia no cubierta, un FMEA que omite el modo de falla más probable. Solo un estudiante con visión sistémica construida a lo largo de C1-C3 puede detectarlos. La Clase 4 es también la última sesión con andamiaje pedagógico (chatbot socrático/adversarial + BUILD). En C5, todo el andamiaje desaparece: el chatbot será neutro, el caso será nuevo, y la única estructura que el estudiante tenga será la que haya internalizado. Lo que C4 consolida, C5 lo mide. **Nota operativa:** Los alumnos recibieron vocabulario técnico el día anterior vía WhatsApp (DD_35). Las ausencias se registran como dato, no se excluyen ni recuperan (DD_36). --- *Protocolo Clase 4 v1.1 · Piloto IA-Socrático · Máquinas y Equipos Industriales* *Facultad de Ingeniería — Departamento de Ingeniería Industrial* *Profesor Ángel Royo - www.angelroyo.com*