IA aplicada donde
tiene sentido.
Identificamos tareas concretas donde la inteligencia artificial puede ahorrar tiempo, ayudar a reducir riesgo o facilitar el acceso al conocimiento. Después las probamos con trabajo real para decidir qué merece implantarse y qué no.
Videollamada · Sin coste
La pregunta no es qué puede hacer la IA. Es qué problema merece que la usemos.
Una herramienta puede ser técnicamente capaz de hacer una tarea y aun así no compensar. Porque cuesta más de lo que ahorra. Porque hay que revisar tanto el resultado que se tarda lo mismo. Porque la tarea se hace tres veces al año. Porque los datos que habría que darle no deberían salir de la empresa.
Por eso el trabajo empieza al revés de como suele plantearse: no desde la herramienta hacia el negocio, sino desde una tarea concreta que hoy cuesta tiempo, dinero o problemas, y desde ahí hacia la herramienta.
Y termina con una recomendación que puede ser incómoda y es igual de válida que las demás: aquí no compensa usar IA.
Tiempo, riesgo y conocimiento.
Como criterio práctico, suelo mirar primero tres tipos de valor: tiempo, riesgo y conocimiento. Empiezo por el tiempo porque suele ser el más fácil de observar y comprobar.
Tiempo
Reducir trabajo repetitivo: resumir documentación, clasificar entradas, preparar borradores, buscar información dispersa, pasar algo de un formato a otro. Es donde el ahorro se ve antes y se comprueba más fácil.
Riesgo
Ayudar a detectar omisiones, inconsistencias o errores, y apoyar revisiones y comprobaciones donde tenga sentido. Aquí la IA no reduce el riesgo por sí sola: puede ayudar a hacerlo cuando el caso y los controles están bien planteados.
Conocimiento
Hacer accesible lo que está repartido: documentación, procedimientos, histórico de clientes, información de producto o lo que sabe la empresa y vive en carpetas que nadie abre.
Que una tarea pueda hacerse con IA no significa que merezca hacerse con IA.
No basta con que una prueba dé una respuesta buena. Hay que saber qué ocurre cuando da una mala.
Es la parte que casi no aparece en las demostraciones, y la que decide si un caso de uso puede salir del entorno de prueba. Cuatro preguntas, antes de implantar nada.
¿Qué consecuencia tiene que la respuesta sea incorrecta?
No es lo mismo un borrador interno que algo que sale al cliente, entra en una factura o alimenta una decisión. El coste del error marca todo lo demás.
¿Podemos detectar el error antes de actuar sobre él?
Hay tareas donde un fallo salta a la vista y otras donde una respuesta equivocada resulta perfectamente verosímil. Las segundas necesitan otro planteamiento.
¿Qué información puede recibir la herramienta?
Datos de clientes, información confidencial, documentación interna. Qué entra y qué no se decide antes de la prueba, no después.
¿Cuándo hace falta revisión humana?
En qué punto alguien tiene que mirar el resultado, con qué criterio y cuánto tiempo cuesta eso. Si la revisión tarda lo mismo que hacer la tarea, el caso no se sostiene.
Estas cuatro preguntas son las que convierten una demostración en una decisión. Un caso de uso no se define solo por lo que hace bien, sino por los límites dentro de los que se le deja trabajar.
¿Es este tu punto de entrada?
Tiene sentido cuando hay una tarea concreta sobre la mesa. Si la pregunta es más amplia, hay una entrada mejor.
Hay un trabajo concreto que quieres hacer mejor.
- Tienes una tarea que consume demasiado tiempo y se repite
- Estás valorando automatizar o asistir un trabajo con IA y no sabes si compensa
- Hay varias ideas sobre la mesa y necesitas decidir cuál probar primero
- Ya habéis experimentado por vuestra cuenta y no sabéis qué merece pasar a uso real
Si la pregunta es más amplia que una tarea.
- Si para introducir IA hay que cambiar procesos, responsabilidades o flujos de información, empieza por transformación digital
- Si lo que falta es el sistema de datos con el que se toman las decisiones, cuadro de medición
- Si el caso de uso ya está definido y lo que falta es que el equipo aprenda a utilizarlo, formación y acompañamiento
- Si ni siquiera sabes dónde está el problema del negocio, diagnóstico
Automatizar con IA un proceso mal diseñado no arregla el proceso. Automatiza su problema.
Y puede reproducirlo más deprisa o a mayor escala. Por eso conviene corregirlo antes: si al mirar la tarea aparece que el problema está en cómo se trabaja, eso va primero.De la tarea a la decisión de implantarla o no.
El alcance se acuerda al principio: cuántas tareas se evalúan, cuántas se prueban y hasta dónde llega la prueba.
Lo que no entra por defecto: rediseñar procesos es transformación digital, formar al equipo de forma general es formación y acompañamiento, y construir el sistema de medición es cuadro de medición. Si un caso lo necesita, se plantea aparte y con su propio alcance.
Detectar, priorizar, probar, decidir.
El ciclo se repite por cada tarea que entre en el alcance. La duración depende de cuántas sean y de lo fácil que sea reunir casos reales para probar.
Detectar
Qué tarea concreta merece que la evaluemos. Sale de hablar con quien la hace cada día, no de un catálogo de casos de uso. Aquí se descartan ya bastantes cosas, a menudo porque se hacen muy de vez en cuando o porque el problema está en otro sitio.
Priorizar
Cuál tiene suficiente impacto potencial y un riesgo razonable como para probarla primero. Impacto potencial, no retorno prometido: si supiéramos el retorno de antemano, no haría falta probar nada.
Probar
Se ejecuta con ejemplos o con trabajo real y se compara contra una referencia: cuánto se tardaba antes, con qué calidad, cuántos errores, cuánta revisión hace falta, cuánto cuesta. La referencia depende del caso, y se fija antes de empezar.
Decidir
Con lo que ha salido, hay cuatro salidas y todas son legítimas:
- Merece pasar a uso real, con sus controles y sus límites
- Necesita cambios en el planteamiento y otra prueba
- La evidencia todavía no basta para decidir
- No compensa usar IA aquí
La última no es un mal resultado. Es haber ahorrado la implantación de algo que no iba a aportar.
Si un caso supera la prueba y necesita desarrollo, integración o configuración técnica, definimos antes de implantar quién lo ejecuta y qué papel asumo yo. Como el resto del alcance, se acuerda al principio y no sobre la marcha.
Casos de uso priorizados, pruebas realizadas
y decisión sobre qué implantar.
Un documento que dice qué se evaluó, qué se probó, qué salió y qué conviene hacer con cada cosa. Incluidas las que no conviene hacer.
- Las tareas evaluadas y por qué entraron en la lista
- Por qué se priorizaron unas antes que otras
- Qué se probó exactamente y en qué condiciones
- Qué evidencia se obtuvo, comparada contra la referencia acordada
- Qué riesgos tiene cada caso y qué controles necesita
- Cuáles avanzan a uso real, con sus límites de uso
- Cuáles necesitan otra prueba y qué habría que cambiar
- Cuáles se descartan, y el motivo
- Siguientes pasos de los casos que sí merecen pasar a uso real
Dime qué tarea te gustaría
hacer mejor con IA.
En 30 minutos podemos ver si merece la pena probarla, si el problema está antes de la herramienta o si probablemente no compensa meter IA ahí.
Videollamada · Sin coste