Ante el aluvión informativo y la confusión que las noticias sobre IA han procurado, muchas empresas, profesionales y particulares han adoptado un enfoque defensivo basado en la combinación del “mantra de la madurez” (la tecnología IA no está madura, las herramientas IA no están maduras, la organización todavía no está madura para absorber la IA) con el “síndrome del prisionero” (la única tecnología buena es la tecnología muerta, porque no puede evolucionar hacia el mal imprevisible) y un hexagrama del I Ching («no es ventajoso moverse en ninguna dirección»), a veces aderezada con la “Táctica de unmatching” (no eres tú: soy yo).

Todas las tecnologías están sujetas a costes de implantación (dinerarios, organizativos y comerciales) y a la aparición de errores en su despliegue. De hecho, si un proyecto software pretende asegurar que no se van a dar errores durante su concepción, diseño, desarrollo, implantación, despliegue o, sobre todo, uso… ¡ni se molesten en abordarlo! Pero, asumiendo que se van a dar errores, éstos se suelen mitigar o camuflar usando el lenguaje apropiado y, esencialmente, tipificándolos, para que parezcan planificados o, al menos, previsibles:

  • Estructurales: debidos a defectos de análisis causados por la falta de experiencia negocial de los analistas software o, según estos últimos, por los defectos en la transferencia de la información adecuada por parte de la empresa en la fase de análisis.
  • Coyunturales: son los defectos estructurales que aparecen en el diseño de la solución software y que los diseñadores software suelen achacar a insuficiencias (salvables) de la organización de la empresa, y que esta última asigna al deficiente trabajo de esos diseñadores.
  • Técnicos: se suelen deber a insuficiencias de las plataformas técnicas que originan sobrecargas, caídas inesperadas de los sistemas o comportamientos erráticos.  Los analistas, diseñadores y desarrolladores software suelen considerar que este asunto no es estrictamente el suyo, por lo que en puridad no se trata de errores que se les puedan imputar. Los técnicos de sistemas, por otra parte, desearían haber participado en las sesiones entre empresa y consultores para calibrar mejor la infraestructura necesaria, en capacidad y precio. Y la empresa, como siempre, piensa que es culpa del software y del hardware, que evidentemente no son cosa suya.

En cualquier caso, como puede apreciarse nítidamente, la empresa está convencida y segura de que habrá errores, y de que los errores no serán culpa suya, sino del proyecto, de los consultores, de la tecnología y, probablemente, de todo lo anterior junto.

En el caso de la IA generativa, los errores que se pueden presumir como parte de ese movimiento de rechazo empresarial a la implantación inmadura de estas herramientas, se alinean también en los mismos ejes que los tipifican:

  • Estructurales IA: los LLMs están sujetos a errores imponderables por alucinaciones, la trazabilidad es imposible y la gestión de la privacidad y confidencialidad de los datos es un infierno.
  • Coyunturales IA: los errores en la implantación y uso intensivo de herramientas IA (¡cuesta llamarlas soluciones IA, como al resto del software!) sobrepasan los beneficios de una pretendida optimización de procesos, que seguramente se alcanzaría invirtiendo los mismos recursos en reformas organizativas.
  • Técnicos IA: las plataformas IA tienen un tremendo coste computacional (y energético, en consecuencia) que favorece la aparición de errores técnicos imprevisibles.

Se ha dado, como puede verse, la inversión de la fábula de la zorra y las uvas que ya imaginó Ambrose Bierce: “A Fox, seeing some sour grapes hanging within an inch of his nose, and being unwilling to admit that there was anything he would not eat, solemnly declared that they were out of his reach”.

¡No están a mi alcance!

La base de esta actitud es reveladora: las empresas tienen razón en señalar todos esos errores porque ya se han dado en proyectos que conocen y que han intentado abordar, sin demasiado éxito o, a veces, con fracasos sin paliativas, la inserción de la IA en procesos productivos, industriales o comerciales. Y esos proyectos, como bien notan, han experimentado los problemas previstos. Pero ésa no es la realidad, sino la percepción real de una situación equivocada. Y esto, claro, merece una cumplida explicación.

Como describí en mi anterior artículo “El martillo IA, dos huevos duros y muchas estrategias”, el planteamiento equivocado es que la IA se aplica bien a lo que pretende la empresa (que conoce poco o nada de la tecnología IA y de sus circunstancias técnicas), bien a lo que apunta el proveedor tecnológico (que no conoce suficientemente los procesos empresariales en los que tiene que intervenir o no tiene experiencia en el análisis estratégico IA de intervención). Es decir: muchos proyectos -que no todos- tienen errores evidentes porque son proyectos evidentemente erróneos.

¿Cómo disminuir en un proyecto IA el número y la importancia de los errores que sin duda acompañarán a su desarrollo? Realizando un análisis estratégico que aúne las consideraciones técnicas (plataformas, riesgos tecnológicos, integración con sistemas heredados) con los aspectos organizativos (inercia personal al cambio, formación orientada-a-procesos) y las proyecciones de negocio (zonas de implantación de bajo riesgo y alto rendimiento, áreas de descompresión tecnológica, ventajas negociales competitivas, etc.). El resultado de este análisis surtirá el efecto de una hoja-de-ruta para la empresa que tendrá en cuenta la gestión de todos los riesgos (la predicción de errores es, sin más, una gestión del riesgo de implantación) y que permitirá a la organización asumir los nuevos esquemas y a los técnicos de infraestructura preparar a la empresa para el cambio.

Si no se cuenta con este análisis estratégico IA, tan sólo cabría decirle a la empresa y a sus stakeholders: ¡Cuidado al empuñar la IA!

P.S.: En un próximo artículo examinaré otra situación habitual que genera peligrosos errores en la implantación de la IA en las empresas: pagar y desarrollar, cuando sólo se debía pagar… o pagar cuando se necesitaba desarrollar. Es fácil: sólo hay que baremar. Lo veremos.