Tu empresa quiere incorporar IA: ¿por dónde empezar antes de comprar herramientas?

En el artículo anterior propuse empezar por el problema y no por la tecnología. Pero ¿qué pasa cuando la empresa ya tiene varios problemas encima de la mesa y para cada uno alguien propone una solución con IA?

Ahí la pregunta cambia. Ya no es solo «¿necesitamos IA?», sino «¿cuál de estas oportunidades merece que le dediquemos tiempo, datos y presupuesto primero?». Y, antes de responder, conviene no confundir elegir un caso con elegir una plataforma. Son decisiones distintas.

No hace falta montar un comité con nombre en inglés ni contratar a un ejército de consultores para empezar. Sí hace falta que quienes conocen el trabajo, quienes pueden cambiarlo y quienes entienden los datos participen en la decisión.

Reunir a las personas que conocen el trabajo #

Una oportunidad de IA suele llegar contada desde un único punto de vista: «El equipo pierde mucho tiempo», «los clientes preguntan siempre lo mismo» o «podríamos automatizar las devoluciones». Es un buen comienzo para conversar, pero no basta para decidir qué construir o comprar.

Para cada propuesta buscaría, como mínimo:

• Una persona responsable del resultado, con capacidad para decidir si el caso sigue adelante.
• Alguien que haga el trabajo hoy, que pueda explicar las excepciones y los pasos que no aparecen en el procedimiento.
• Una persona de tecnología o datos, que ayude a entender integraciones, calidad, permisos y esfuerzo.
• Seguridad, privacidad, legal u otros perfiles, cuando los datos, las personas afectadas o el impacto de un error lo hagan necesario.

En una empresa pequeña, una persona puede asumir varios papeles. Lo importante no es dibujar un organigrama nuevo, sino evitar que el caso se defina solo entre quien pide la herramienta y quien la vende.

También preguntaría qué herramientas usa ya el equipo. Puede haber funciones de IA activadas dentro de un producto existente o servicios contratados por distintas áreas. No hay que asumir que toda empresa ya los usa, ni que todas las herramientas tratan los datos igual: conviene comprobar sus condiciones y qué información está permitido compartir.

Comparar oportunidades, no demos #

La guía de planificación de IA de Microsoft recomienda partir de problemas de negocio y valorar, entre otros aspectos, su impacto, viabilidad y recursos disponibles. Es una orientación útil, aunque Microsoft también vende tecnología: no hace falta adoptar sus productos para aprovechar la pregunta.

El Playbook del marco de gestión de riesgos de IA de NIST añade una perspectiva complementaria: documentar el propósito, el contexto, las personas afectadas y las alternativas sin IA. El marco es voluntario, no una certificación ni una receta que garantice buenos resultados.

Con esas ideas, compararía cada oportunidad con las mismas preguntas. No asignaría una puntuación universal ni fingiría que «alto» vale exactamente lo mismo en todas las empresas:

1. Impacto: ¿qué resultado queremos mejorar y a quién le importa?
2. Viabilidad: ¿tenemos datos pertinentes, actuales y accesibles con permiso?
3. Esfuerzo y capacidades: ¿qué integraciones, conocimientos y cambios de proceso harían falta?
4. Riesgo y reversibilidad: ¿qué pasa si la salida es incorrecta y podemos corregirla o deshacerla?
5. Medición: ¿podemos observar la calidad y el coste del trabajo completo, no solo contar respuestas generadas?

Una nota baja no descarta automáticamente un caso; ayuda a ver qué falta por averiguar. En cambio, hay motivos para no avanzar mientras no se resuelvan: no tener autorización para usar los datos, no saber quién responde por el resultado o no poder evaluar un error que podría causar un daño relevante.

La guía de Google sobre reglas de machine learning aconseja medir el sistema actual y considerar soluciones sencillas antes de añadir aprendizaje automático. Está escrita para ingeniería de machine learning, no es un estudio de retorno de la IA generativa, pero la advertencia sirve: una demo vistosa no es una línea base.

Un ejemplo: tres ideas para las devoluciones #

Imaginemos una tienda en línea que quiere mejorar cómo gestiona devoluciones. No hay cifras ni resultados de una empresa real; es un ejemplo para mostrar cómo cambia la decisión al comparar alcances distintos.

De momento, la primera parece más fácil de acotar. Eso no demuestra que vaya a ahorrar tiempo ni que sea la mejor opción: solo indica qué hipótesis podríamos comprobar antes, siempre que los datos y la revisión sean adecuados.

Tampoco mezclaría los tres casos en un «agente que gestiona devoluciones». Preparar texto, clasificar una solicitud y autorizar un pago son tareas distintas, con errores y consecuencias distintos. Si la IA aporta valor en una etapa, no hace falta entregarle las demás.

Dejar por escrito qué tendría que ser verdad #

Antes de pedir una prueba, escribiría una ficha breve, no para producir documentación por deporte, sino para que dentro de unas semanas podamos distinguir una mejora de una demo que gustó en la reunión:

• Tarea y responsable: qué se intenta mejorar y quién puede continuar o detener el trabajo.
• Proceso de referencia: cómo se hace hoy y qué resultado queremos observar.
• Datos y permisos: qué información puede utilizarse, de dónde sale y qué queda expresamente fuera.
• Calidad y revisión: qué debe cumplir una respuesta y quién revisa las salidas antes de que tengan efecto.
• Coste y esfuerzo: qué recursos consume la solución completa, incluida la integración y el tiempo de las personas que revisan.
• Límites y salida: qué errores no son aceptables, cómo se corrigen y bajo qué condición paramos.

La función Measure de NIST recomienda definir medidas y límites de rendimiento, y documentar aquello que no se ha podido medir. En la práctica, tomaría una pequeña muestra de tareas reales y registraría cómo funciona hoy: tiempo total, calidad, errores y revisiones. Después compararía la propuesta con esa referencia usando la misma unidad de trabajo.

Un objetivo como «que responda más rápido» no ayuda mucho si no sabemos cuánto tarda hoy ni qué significa una respuesta correcta. Y medir solo cuánto tarda en generar un borrador deja fuera el tiempo de comprobación, corrección e integración. La tarea no está resuelta cuando aparece texto en la pantalla; está resuelta cuando alguien puede usar el resultado con la calidad acordada.

Personas y normas también forman parte de la preparación #

Quien use o supervise un sistema, necesita entender, al menos, qué hace, qué no hace y cómo tratar sus resultados. En la Unión Europea, el artículo 4 del Reglamento de IA establece obligaciones relacionadas con la alfabetización en IA para proveedores y responsables del despliegue. La explicación de la Comisión Europea aclara que las medidas deben tener en cuenta el conocimiento y el contexto, y que no se exige garantizar un nivel individual concreto.

Esto no significa que todas las empresas necesiten la misma formación, una certificación o un curso específico. La obligación aplicable depende del papel de la organización y del sistema; para una decisión de cumplimiento hay que revisar la norma vigente y pedir asesoramiento jurídico cuando corresponda.

El primer paso puede ser decir «todavía no» #

Si no sabemos quién responde por la decisión, no tenemos permiso para usar los datos o no podemos reconocer un resultado inaceptable, no tenemos que comprar una herramienta para descubrirlo. Podemos aplazar ese caso, mejorar el proceso o escoger otra oportunidad que sí permita aprender sin asumir un riesgo que no sabemos gestionar.

Cuando ya tengamos varias opciones comparables, elegiremos una hipótesis, no una promesa de ahorro. En el siguiente artículo hablaremos sobre diseñar el piloto: qué muestra usar, cómo revisar los resultados y qué evidencia justificaría continuar o parar.

La IA no necesita ganar una presentación, necesita ganarse un sitio en el trabajo real.

Fuentes y alcance #

• Plan for AI adoption — Microsoft Cloud Adoption Framework: guía de un proveedor; sus recomendaciones no obligan a elegir sus servicios.
• NIST AI RMF Playbook — Map y Measure: orientación voluntaria sobre contexto, riesgos, medidas y límites. NIST indica que el marco está en revisión.
• Rules of Machine Learning — Google: guía de ingeniería centrada en machine learning; no es evidencia de retorno aplicable a cualquier sistema de IA.
• AI literacy Q&A — Comisión Europea y Reglamento (UE) 2026/1744: información sobre la modificación de 2026 relacionada con el artículo 4 del Reglamento de IA. No sustituye una valoración jurídica del caso concreto.