Cómo hacer una prueba de concepto de IA en dos semanas (sin que se alargue a seis meses)

Por qué la mayoría de las POC de IA no llegan a ninguna decisión

La tecnología casi nunca es el problema de una POC de IA. El problema es que nunca tuvo fecha de cierre. Alguien arma una primera versión con datos de ejemplo, el equipo se entusiasma en la demo, y de ahí en adelante entra en un limbo que se llama “seguimos evaluando”. Pasan dos meses, después cuatro, y nadie recuerda cuál era el número que iba a decidir si esto seguía o se cerraba, porque nunca se escribió uno.

Ese limbo tiene un costo real: mientras la POC “sigue en evaluación”, el equipo técnico está ocupado en algo que no produce una decisión, el dueño del proceso pierde la paciencia porque nadie le devuelve un resultado claro, y la dirección empieza a tratar cualquier proyecto de IA como algo que “nunca se sabe cuándo termina”. Ese descrédito es más caro que cualquier POC fallida: contamina la siguiente conversación sobre IA en la empresa.

El fondo del problema no es de ejecución técnica, es de diseño del experimento. Una POC sin plazo fijo, sin criterio de éxito escrito y sin alcance acotado a un solo proceso no es un experimento: es un proyecto sin nombre que nadie se atreve a cerrar. Esta guía asume que ya se hizo el trabajo previo (identificar el dolor, elegir el caso de uso, tener claro el porqué) y se enfoca en el paso siguiente: cómo ejecutar esa POC en catorce días exactos, con una decisión al final.

Qué es en concreto una POC de IA de dos semanas

Una POC de IA en dos semanas no es una demo ni un experimento de investigación abierto. Es un ejercicio acotado, con fecha de inicio y de cierre fijadas de antemano, que busca responder una sola pregunta: ¿esta IA resuelve este proceso específico lo suficientemente bien como para justificar invertir en escalarlo? Nada más amplio que eso.

La palabra clave es “funcional”. Una POC que corre solo con datos inventados o con los tres ejemplos más fáciles que el equipo pudo encontrar no prueba nada: prueba que el modelo puede seguir instrucciones, que ya se sabía. Una POC real corre sobre datos reales del proceso, aunque sea un subconjunto, y produce un resultado que alguien del negocio puede evaluar con sus propios criterios, no con los del equipo técnico.

• Un piloto silencioso que se extiende sin fecha de cierre porque “todavía estamos afinando”.
• Una demo con datos de ejemplo elegidos para que todo salga bien.
• Un proyecto de IA para “explorar posibilidades” sin un proceso ni un KPI específico detrás.
• Un desarrollo completo con integración a todos los sistemas: eso es fase de escalamiento, no de POC.

Qué se define antes de escribir una línea de código

Todo lo que decide si la POC funciona ocurre antes del día uno. Si esto se salta, las dos semanas se van en discusiones sobre qué se suponía que se estaba probando, en lugar de construir y medir. Cuatro cosas tienen que estar escritas y acordadas antes de empezar.

1. Acota a un solo proceso, medible

No “probemos IA en atención al cliente”. Sí “clasificar y priorizar los tickets de soporte que hoy tardan más de cuatro horas en primera respuesta”. El proceso tiene que ser lo bastante chico para caber en dos semanas y lo bastante repetido para que el resultado sea representativo, no una anécdota.

2. Define el criterio de éxito antes, no después

Un número y un umbral, escritos y firmados por el dueño del proceso antes de empezar: por ejemplo, “el sistema clasifica correctamente al menos el 80% de los tickets frente a la clasificación manual” o “reduce el tiempo de primera respuesta de cuatro horas a menos de una”. Si el criterio se define después de ver el resultado, deja de ser un criterio: es una justificación.

3. Confirma qué datos reales existen y son accesibles

Antes de escribir código se responde: ¿existen al menos unos cientos de instancias reales de este proceso en los últimos meses? ¿están en un formato al que se puede acceder en los primeros dos días, o hay que pedir permisos que tardan semanas? Si la respuesta a la segunda pregunta es “hay que pedir acceso”, ese trámite se resuelve antes del día uno, no durante la semana uno.

4. Nombra quién decide al final

Una persona con autoridad para decidir escalar, ajustar o descartar, que se compromete a dar esa respuesta el último día. Sin esa persona identificada de antemano, la POC termina exactamente donde empezó: en “seguimos evaluando”.

Semana 1: setup, datos y una primera versión que funciona

La primera semana no es para perfeccionar nada. Es para tener, al final del día cinco, una versión que corre sobre datos reales y produce un resultado que alguien puede mirar. Perfeccionar viene después, si acaso hay un después.

Día 1-2: acceso a datos y arquitectura mínima

Se consigue el acceso real a los datos del proceso (no una muestra curada) y se define la arquitectura más simple que puede funcionar: qué modelo, qué integración mínima, qué se automatiza y qué queda manual por ahora. La regla es la misma que usan los equipos que construyen agentes en serio: empezar con el bloque más simple que puede resolver el problema y agregar complejidad solo si el resultado lo exige, nunca antes.

Día 3: primera versión funcional, aunque sea fea

Al tercer día tiene que existir algo que corre de principio a fin sobre datos reales, aunque la interfaz sea un script de línea de comandos o una hoja de cálculo. El objetivo no es que se vea bien, es que produzca un resultado verificable sobre el proceso real, no sobre un ejemplo de juguete.

Día 4-5: prueba interna y ajuste con el equipo técnico

Se corre la primera versión contra un lote más grande de casos reales, se comparan los resultados contra lo que un humano habría decidido, y se ajusta lo mínimo indispensable. El día cinco cierra con una versión estable, no perfecta, lista para que la vea alguien fuera del equipo técnico.

Semana 2: prueba con usuarios reales, medición y decisión

La segunda semana cambia de dueño: deja de ser un ejercicio del equipo técnico y pasa a manos de quien opera el proceso todos los días. Si en esta semana solo el equipo que construyó la POC la está probando, la POC no sirvió de nada: valida que funciona en el laboratorio, no que funciona en la operación real.

Día 6-7: uso real por parte de quien opera el proceso

El dueño del proceso (o el equipo que lo ejecuta a diario) usa la versión sobre casos reales que van llegando, no sobre un set de pruebas preparado. Se registra cada caso donde el resultado no coincide con lo que un humano habría hecho, y por qué. Esta es la información más valiosa de toda la POC: revela si el problema está en el modelo, en los datos o en cómo se planteó el proceso.

Día 8-9: ajuste dirigido por los errores reales

Se corrigen únicamente los problemas que aparecieron en el uso real de los días seis y siete, no una lista nueva de ideas que a alguien se le ocurrieron en el camino. Agregar alcance en este punto es la forma más común de que una POC de dos semanas se convierta en una de seis.

Día 10: medición final y decisión

Se mide el resultado contra el criterio de éxito escrito antes de empezar, sin negociarlo en el momento porque el número quedó corto. La persona designada para decidir da su respuesta ese mismo día: escalar, ajustar el alcance y correr una segunda POC más acotada, o descartar. Las tres son un cierre válido. La única respuesta que no es válida es “necesitamos más tiempo para seguir viendo”.

Errores que convierten una POC de dos semanas en un proyecto eterno

• Probar con datos curados o inventados en vez de datos reales del proceso: el resultado se ve mejor de lo que será en producción, y esa diferencia se paga después, ya con presupuesto comprometido.
• No fijar el criterio de éxito por escrito antes de empezar: sin ese número, cualquier resultado se puede interpretar como “prometedor” y la decisión se pospone indefinidamente.
• Dejar que solo el equipo técnico use y evalúe la POC: valida la tecnología, no si sirve para el proceso real ni si el equipo que lo va a operar confía en el resultado.
• Sumar alcance durante la segunda semana porque “ya que estamos, probemos también con esto”: cada caso de uso nuevo que se agrega resetea el reloj de las dos semanas.
• No tener a alguien con autoridad para decidir al final: sin esa persona, la POC exitosa se queda esperando aprobación y la POC fallida nunca se cierra formalmente.

Cómo se ve esto en la práctica

Una empresa de servicios financieros mediana tenía un problema puntual: el equipo de soporte tardaba en promedio cuatro horas en dar primera respuesta a un ticket, porque antes de responder alguien tenía que leerlo completo y decidir a qué área derivarlo. El dolor ya estaba identificado, el proceso ya estaba mapeado. Lo que faltaba era decidir si un sistema de clasificación automática servía o no.

El alcance se acotó a un solo tipo de ticket (los de facturación, que eran el 40% del volumen) y el criterio de éxito quedó escrito antes de empezar: clasificar correctamente al menos el 85% de esos tickets frente a la derivación manual, medido sobre dos semanas de tickets reales entrantes. La primera semana se usó para conectar el sistema a los tickets reales del último trimestre y tener una versión funcional el día tres.

En la segunda semana, dos agentes de soporte (no el equipo técnico) usaron la clasificación automática sobre los tickets que iban llegando de verdad, y marcaron cada vez que la clasificación no coincidía con lo que ellos habrían hecho. El resultado del día diez: 88% de acierto, por encima del umbral. La decisión fue escalar, pero solo a los tickets de facturación primero, no a todo el volumen de soporte de una vez. Esa segunda fase ya no fue una POC: fue un proyecto con presupuesto, porque el número ya existía para justificarlo.

Mi criterio

Cómo se mide si la POC salió bien

El éxito de una POC no se mide en si “la IA funcionó”. Se mide en si al final de las dos semanas existe una decisión clara, tomada con datos reales, que alguien con autoridad puede defender frente a la siguiente pregunta de presupuesto.

• El resultado cuantitativo contra el criterio de éxito escrito antes de empezar (no uno ajustado después para que calce).
• Si el proceso se probó con datos reales del volumen real, no con una muestra curada.
• Si la persona que opera el proceso a diario confía en el resultado, no solo el equipo técnico que lo construyó.
• Si al final de las dos semanas existe una decisión explícita (escalar, ajustar o descartar), documentada y con dueño.
• Cuánto costó realmente la POC en tiempo de las personas involucradas, para comparar contra el valor que promete escalarla.

Si después de dos semanas la respuesta es “necesitamos más tiempo para estar seguros”, eso no es un resultado abierto: es que el criterio de éxito nunca estuvo lo bastante claro desde el principio. La corrección no es extender el plazo, es volver al paso de antes de empezar y escribir el número que faltaba.