Actividad Integradora 3 IA y toma de decisiones

Le pedí a otra IA que revisara mi propuesta

No le pedí que decidiera por mí (eso ya lo hice en la página anterior), sino que la pusiera a prueba, como lo haría un consultor externo antes de aprobarla. Abajo está el prompt exacto, la respuesta completa sin editar, y después mi evaluación de qué me sirve y qué no.

Evidencia

Prompt utilizado

Modelo Claude Haiku, mediante Claude Code. Le di el diagnóstico, la decisión ya tomada y las cinco acciones; le pedí que la evaluara, no que la rehiciera.

Actúa como consultor externo de gestión de operaciones. NO uses herramientas ni leas archivos: responde únicamente con tu análisis en texto, basándote solo en la información que te doy a continuación. CONTEXTO DE LA EMPRESA Custronix es una pequeña empresa de servicios informáticos (6 empleados) en Ecuador, con tres líneas de servicio: custodia digital/ciberseguridad, electrónica y domótica, y migración de sistemas a Unix/Linux. EL PROBLEMA (medido sobre 40 proyectos entre marzo y agosto de 2026) - Solo el 22,5% de los proyectos se entrega en la fecha pactada. El plazo pactado promedia 4,08 días y el real 6,88 días (+68,6%). - Con más de 4 proyectos simultáneos en curso, el retraso medio pasa de 2 a 4,91 días (2,5 veces más). Correlación proyectos simultáneos-retraso: r=0,373. - La línea de electrónica/domótica no cumplió un solo plazo (0% de 11 proyectos); en el 45,5% de sus proyectos faltó material de terceros al iniciar. - Análisis de causas (Pareto): sobrecarga del equipo 40,2% de los días perdidos, falta de repuestos 26,8%, cambios de alcance del cliente 13,4% (estas tres suman 80,4%). - La satisfacción del cliente (CSAT) cae de 4,78/5 cuando se entrega a tiempo a 3,21/5 cuando el retraso supera 5 días (r=-0,919). LA PROPUESTA YA DECIDIDA Se seleccionó la alternativa "Límite de proyectos en curso + puerta de entrada": no aceptar fecha de entrega para un proyecto nuevo sin confirmar antes que hay capacidad libre (tope de 4 proyectos simultáneos) y que el material necesario está disponible. Se descartó contratar personal adicional (no ataca la causa raíz de admisión sin control) y se descartó, por ahora, negociar stock/proveedor alterno (requiere más tiempo y capital). LAS CINCO ACCIONES PROPUESTAS 1. Definir el límite de proyectos en curso: tablero Kanban compartido (columnas en cola/en curso/entregado); un proyecto nuevo solo entra si hay espacio libre. Responsable: administrador de sistemas (fundador). Recursos: tablero gratuito, sin costo. 2. Puerta de entrada antes de prometer fecha: checklist de 5 puntos (línea de servicio, material crítico confirmado, técnico disponible, alcance por escrito, fecha dentro del cupo) que ventas completa antes de cerrar el trato, validado por el técnico de la línea. Recursos: plantilla, 2 horas de diseño. 3. Recalibrar el plazo ofertado por línea de servicio, en vez de un plazo parejo de 4 días para las tres líneas (domótica realmente toma 8,3 días medidos). Responsable: gerencia comercial. 4. Mantener una bitácora de los mismos diez datos ya usados en el diagnóstico, para todo proyecto futuro, no solo los 40 ya medidos. Responsable: cada técnico alimenta, el fundador consolida mensualmente. Recursos: la plantilla de Excel ya existente. 5. Revisión mensual de indicadores (cumplimiento SLA, retraso medio, CSAT) para ajustar el límite de 4 si la demanda cambia. Responsable: administrador de sistemas con el equipo completo. TU TAREA Evalúa esta propuesta como si fueras un consultor externo que la revisa antes de que se implemente. Responde en tres bloques: BLOQUE 1 — EVALUACIÓN GENERAL: ¿la propuesta ataca bien las causas identificadas? ¿hay algo importante que se le escapa o que podría fallar en la práctica? BLOQUE 2 — TRES RECOMENDACIONES para fortalecer la propuesta (no para reemplazarla), concretas y accionables. BLOQUE 3 — UN RIESGO u objeción que un dueño de la empresa probablemente plantearía antes de aprobar esto, y cómo se le respondería. Sé concreto, breve y no repitas los datos que ya te di; ve directo al análisis.

Resultado obtenido

Respuesta completa, sin editar

BLOQUE 1 — EVALUACIÓN GENERAL Aciertos principales: la propuesta toca bien la causa dominante (sobrecarga, 40,2% de retrasos). El límite de 4 tiene asidero: r=0,373 es significativo, y la correlación entre paralización y retraso está clara (2 a 4,91 días). El checklist de puerta cubre la causa de falta de material validando disponibilidad antes de comprometer. La recalibración de plazos por línea es crítica: domótica de 4 a 8+ días es un reconocimiento importante. Mantener bitácora permite ajustes. Brechas importantes: 1. Cambios de alcance solo está parcialmente contenido: "alcance por escrito" en el checklist previene cambios iniciales ignorados, pero no los cambios que el cliente solicita durante la ejecución. Sin protocolo de cambios formales, se seguirán perdiendo días. 2. La brecha de puntualidad no cierra solo con el límite de 4: incluso si el límite reduce los retrasos a 5,5 días, sigue sin cumplirse el plazo de 4 días pactado. Esto sugiere que recalibrar los plazos ofertados es más crítico que el límite de 4, aunque aparece en tercer lugar. 3. Capacidad sin crecimiento, vulnerabilidad comercial: con seis personas y un límite de 4 proyectos simultáneos, ¿qué pasa cuando llega un cliente nuevo con la capacidad llena? La propuesta no define la política de "puerta cerrada". BLOQUE 2 — TRES RECOMENDACIONES 1. Protocolo formal de cambios de alcance durante ejecución: añadir a la bitácora un campo de "cambios de alcance solicitados" y definir que cualquier cambio en marcha se trata como proyecto micro (1-2 días) o cambio formal firmado por el cliente con impacto en tiempo y costo. 2. Sub-límites por línea de servicio, no solo un límite global de 4: por ejemplo, máximo 1 domótica + máximo 2 ciberseguridad + máximo 1 migración en curso a la vez, para que domótica en cola no congele las otras líneas. 3. Buffer explícito en el plazo ofertado, interno frente a externo: no solo recalibrar domótica a 8 días, sino ofertar 9 días al cliente y planificar internamente 8, absorbiendo contingencias sin que el cliente lo note. BLOQUE 3 — UN RIESGO Y SU RESPUESTA Objeción esperada del dueño: "Si limitamos a 4 proyectos y rechazamos solicitudes, perdemos facturación. ¿Cuál es el impacto en ingresos?" Respuesta: el riesgo es real, pero la métrica está invertida. Con 22,5% de cumplimiento actual, ya se están perdiendo clientes por insatisfacción. Una empresa de 6 personas depende de la retención y las referencias; un cliente insatisfecho es un costo alto. El análisis correcto compara el costo de un cliente perdido contra el ingreso de un proyecto rechazado en un semestre, y probablemente muestre que limitar la admisión es rentable.

Evaluación

Qué incorporo, qué descarto, y por qué

Incorporo

Protocolo de cambios de alcance en marcha. Tiene razón: mi checklist solo cerraba el alcance al inicio, no durante la ejecución. Sumé a la Acción 2 que todo cambio pedido ya empezado el trabajo se registra como cambio formal, con el cliente confirmando por escrito el nuevo plazo.
Colchón interno no comunicado al cliente. En vez de ofertar exactamente el plazo medido en domótica, sumé un día de margen interno a la Acción 3: se planifica más corto de lo que se promete, no al revés.

Reviso con cuidado

El argumento de que rechazar proyectos sale rentable. La idea general (que un cliente insatisfecho cuesta más que un proyecto rechazado) es razonable. Pero la apoya diciendo que el "77,5% de los proyectos insatisfechos" (el porcentaje que incumple el plazo), cuando el CSAT promedio real es 4,17 sobre 5: bastante bueno. Solo cae con fuerza en los retrasos de más de cinco días. Uso el argumento, pero con el dato correcto, no con el suyo.

Descarto

Los sub-límites por línea de servicio (1+2+1). Se sacó esos números de la manga (ella misma escribe «los números ajustan»); no vienen de ningún dato que le di. Con solo seis personas, fijar cupos separados por línea puede dejar a alguien sin trabajo mientras otra línea tiene cola. Prefiero un límite global y revisarlo cada mes con datos reales, como ya prevé la Acción 5.
La cifra de "retrasos de 5,5 días" tras aplicar el límite. Ese número no está en nada de lo que le di. Lo comprobé contra mi propio conjunto de datos: los proyectos que ya cumplen las dos condiciones de la propuesta (carga baja y material a tiempo) tienen un retraso medio real de 1,05 días, no 5,5: parece haber confundido «retraso» con «días totales de entrega». Es el ejemplo más claro de por qué cada número de una IA hay que confirmarlo antes de repetirlo.

Riesgos del uso de IA

Cuatro riesgos, aplicados a este caso concreto

Privacidad

El prompt que envié lleva cifras agregadas (porcentajes, promedios) pero no nombres de clientes ni de proyectos. Aun así, en una empresa de seis personas ese cuidado hay que mantenerlo siempre: bastaría con escribir «el proyecto de tal cliente» para que un dato hoy anónimo deje de serlo.

Sesgos

Los indicadores que le di a la IA salen de 40 proyectos de seis meses, de una sola empresa. La IA no tiene forma de saber si marzo-agosto es representativo o si, por ejemplo, diciembre se comporta distinto. Cualquier recomendación suya hereda el sesgo de la muestra que yo mismo construí.

Transparencia

La IA no explica por qué prioriza una recomendación sobre otra: entrega el resultado, no el razonamiento. No hay manera de auditar cómo llegó a él, así que cada sugerencia se evalúa por su contenido, nunca por la confianza con la que está redactada, y esta consulta lo probó: la citaré abajo.

Responsabilidad

Si el límite de 4 proyectos resulta mal calibrado y Custronix pierde un cliente por rechazarlo, la responsabilidad es mía, no de la IA. Consultarla no traslada la decisión ni la reparte; solo agrega un punto de vista antes de que yo decida.

La IA se usó como herramienta de apoyo, no como quien decide: la decisión de la Alternativa A ya estaba tomada antes de consultarla, y se mantiene después, con dos ajustes concretos que sí valieron la pena y dos ideas que no pasaron la prueba de mis propios datos.