Termina 2025 y es un buen momento para reflexionar sobre lo más destacado que he vivido como consultor en el sector de la automatización de soluciones. Si bien las soluciones de factura electrónica en Europa merecen un capítulo aparte (prometo hablar de ello en 2026), hoy quiero centrarme en la Inteligencia Artificial Generativa. Sin duda, ha sido la protagonista de este año, ocupando la mayor parte de mis reuniones, formaciones, debates y desafíos

IA Generativa: Entre el Hype y la Realidad

No hay semana en la que no aparezca alguien con una nueva publicación, estudio o promesa sobre la IA Generativa. ¿No os empieza a resultar un poco agotador? También se percibe cierta urgencia por parte de muchas empresas para subirse a este tren, a veces sin tener claro el destino, y con el mensaje (casi amenazante) de que “si no inviertes en IA, te quedas atrás”.

En lo personal, reconozco que la IA Generativa nos ha facilitado el día a día: informes mejorados, presentaciones más pulidas, emails más claros, acceso rápido a información que antes costaba encontrar… especialmente útil cuando sabes cómo sacarle partido. El consumo de estos servicios sigue creciendo, y es innegable que son herramientas valiosas para muchos profesionales.

Sin embargo, cuando nuestros clientes valoran invertir en proyectos de IA Generativa, el prisma cambia: lo que realmente importa es el retorno de la inversión (ROI), ya sea a través de reducción de costes, aumento de la productividad o cumplimiento normativo. No basta con tener IA por tenerla; es fundamental que aporte un valor claro y concreto. Y, curiosamente, sobre casos concretos y tangibles no hay tantas publicaciones.

Agentes de IA y el Verdadero ROI

Aquí es donde entran los tan mencionados “Agentes de IA”: soluciones que automatizan procesos concretos apoyándose en motores de IA, capaces de tomar decisiones y liberar al usuario de tareas repetitivas. En esa automatización real es donde está el ROI.

Pero esto no es fácil, y los retos abundan. Seguro que muchos habéis oído hablar del estudio del MIT publicado en agosto que indica que la mayoría de pilotos de IA Generativa fracasan. ¿Sabéis que la mayoría de gente que comenta sobre este informe no lo ha leído?

Por ponerlo en contexto, no es un estudio técnico ni un informe de investigación profunda, sino un análisis basado en entrevistas a un número limitado de empresas y considera “fracaso” el no lograr un ROI claro en unos pocos meses. Personalmente, me parece un criterio bastante exigente para calificar un proyecto fallido. Es importante destacar que esto no significa necesariamente que los proyectos no hayan funcionado, sino que no han generado un beneficio claro para la empresa en ese plazo.

Aun así, el mensaje de fondo es válido: numerosos pilotos de IA no tienen sentido porque en muchas ocasiones se lanzan sin unos objetivos claros, simplemente para justificar la inversión en un departamento de IA. Otras veces, se pasa por alto que los procesos de negocio son complejos y están llenos de interacciones, por lo que no es suficiente con centrarse solamente en la IA Generativa y se debe disponer de otro tipo de aplicaciones de automatización.

La IA Generativa es una Herramienta, No el Centro del Universo

En reuniones con grandes empresas (IBEX35), me surge siempre la misma duda: ¿tiene sentido que tengan departamentos de IA independientes? Lo que está claro es que la IA Generativa no puede automatizar procesos por sí sola. Necesita integrarse con el resto del ecosistema de la empresa (servicios web, bases de datos, RPA, ERPs, CRMs, email, etc.), gestionar las excepciones con usuarios y coordinarse con otros procesos de negocio.

Por eso, veo la IA Generativa como una herramienta más dentro de un conjunto de soluciones de automatización. No es una solución en sí misma, sino un componente que, bien utilizado, potencia el resto.

Muchas empresas ya usan soluciones de automatización de procesos que han demostrado ser efectivas. Simplemente se debe incorporar la parte de IA Generativa que se necesite para cada proceso. La mayoría de estas soluciones ya incluyen este tipo de integraciones. Por eso, considero que lo más sensato es seguir confiando en los equipos encargados de la Optimización de Procesos (se llamen Operational Excellence, Continuous Improvement, Digital Transformation, o de cualquier otra manera) y capacitarlos en IA Generativa, para que puedan aprovechar al máximo todas las herramientas disponibles.

En el pasado ocurrió algo similar con la llegada de la tecnología RPA, cuando grandes empresas crearon departamentos exclusivos centrados en dicha tecnología. Hoy día, casi todos han desaparecido y se han integrado dentro de los equipos de optimización de procesos.

Mirando al 2026

El principal desafío de la IA Generativa es su naturaleza no determinista. Esto significa que, aunque se le plantee exactamente la misma pregunta (mismos parámetros de entrada), es posible que no siempre genere la misma respuesta. Esta característica dificulta la automatización de procesos o tareas repetitivas, ya que la falta de consistencia puede complicar la integración en flujos de trabajo que requieren resultados predecibles.

Por eso en 2025 la mayoría de los esfuerzos se han centrado en aplicar IA Generativa en una serie de departamentos concretos, en los que no es tan importante ser consistente; Atención al cliente (manejo de casos de soporte, gestión de peticiones de información, recolección de feedback), Marketing (creación de contenido y market research) e IT (desarrollo de software, soporte y ciberseguridad).

Sin embargo, aquí no se encuentra el core del negocio de las empresas ni la mayoría de las tareas repetitivas (backoffice)—donde la automatización suele aportar mayor valor. Por ello, considero que debemos replantear nuestra mentalidad y aceptar cierto grado de indeterminación en el uso de la IA, en lugar de aspirar a un automatismo completo. Pienso que automatizar entre el 75% y el 80% de estos procesos ya podría generar un retorno de inversión significativo. Por supuesto, es fundamental gestionar adecuadamente el 20-25% restante de incidencias, posiblemente mediante la interacción del proceso con gestores humanos ¡Espero que el año próximo podamos dar el salto a este tipo de soluciones!

Mientras tanto, sigo pensando que las expectativas sobre la IA Generativa siguen demasiado altas. Cuando se moderen, podremos apreciar su verdadero valor: ser una herramienta más, aunque muy poderosa, para automatizar procesos y mejorar la eficiencia en distintos ámbitos.

¡Os deseo a todos un gran 2026, lleno de proyectos útiles, menos hype y más resultados concretos!

Si alguna vez te has preguntado por qué todo el mundo usa la inteligencia artificial generativa a nivel personal pero se ven pocos casos de uso en el mundo empresarial, aquí van 3 razones que pueden explicarlo:

Es muy genérica; la IA Generativa ha aprendido basándose en millones de datos, pero estos datos son generales, los que se han podido recopilar de miles de fuentes que son públicas. Sin embargo, una empresa toma decisiones en base a datos de su propio negocio, que son privados. Estos datos no han podido sido aprendidos, por lo que la IA no ofrece buenas respuestas a las preguntas sobre cada negocio particular.

Alucina: la IA Generativa produce respuestas sin sentido de vez en cuando, lo que se conoce como Alucinaciones. Al faltar el contexto de negocio, las alucinaciones son mucho mayores cuando las preguntas se refieren a casos empresariales.

Está Desfasada: la IA Generativa no está actualizada. Ha aprendido muchos datos, pero de fechas pasadas ya que el esfuerzo para recoger información nueva es enorme. Esto significa que no contempla información de las últimas semanas o últimos meses.

¿Cómo lo solucionamos?

La opción más obvia sería crear un modelo personalizado para cada negocio, enseñando a la IA con nuestros propios datos. El problema de esta opción es que es demasiada costosa en tiempo y dinero.

Por eso hoy día cada vez veo más soluciones que utilizan RAG (Retrieval Augmented Generation), que es una manera de personalizar el modelo general de IA Generativa, dándole el contexto adecuado antes de contestar a nuestra pregunta.

Para ello, primero recogemos los documentos de negocio relevantes, los indexamos e introducimos en forma de vectores en una base de datos. Después, al hacer nuestras preguntas, pedimos a la IA Generativa que entienda lo que queremos, pero conteste usando solamente la información de la documentación almacenada. También podríamos indicar los documentos al mismo tiempo que hacemos la pregunta sobre ellos.

Con esta técnica eliminamos las alucinaciones completamente porque tendremos respuestas basadas en nuestros documentos. Además, la solución siempre estará actualizada ya que vamos indexando nuevos documentos a medida que se generan.

Dentro del proceso de venta de una solución software se pueden encontrar distintos perfiles que participan de una u otra manera en algún momento. Por descontado que el actor principal es el comercial, pero también se trabaja con telemarketing, marketing, preventa, servicios profesionales, soporte a ventas o departamento legal.

Los consultores de preventa conocen el software que se ofrece y participan en actividades tales como presentaciones técnicas, demostraciones, pruebas de concepto, respuesta de solicitudes de información, etcétera.

Hace 20 años era muy habitual buscar consultores de preventa para que aprendieran muy bien la herramienta de software, por lo que existía una tendencia a buscarlos con grandes capacidades técnicas; mejor si era capaz de programar, tenía experiencia en bases de datos o conocía bien el funcionamiento de los protocolos de red.

¿ Pero esto sigue siendo así hoy en día ?

En este vídeo hago una reflexión sobre el tema

Durante mi trayectoria laboral he participado en muchas Pruebas de Concepto (POC en inglés) utilizando diversas soluciones software. Las POCs son un recurso que se utiliza a veces durante la fase de venta para demostrar una serie de funcionalidades específicas y acordadas de antemano. 

Como la POC puede suponer un esfuerzo de trabajo importante sin saber realmente si va a terminar convirtiéndose en una venta, nosotros (los fabricantes de software) solamente las hacemos cuando vemos un claro compromiso de compra en un cliente que quiere confirmar que la solución funcionaría con sus requisitos de negocio particulares. Como norma general no cobramos por este trabajo ya que nuestro objetivo es la venta de la solución.

Una alternativa clara a las POCs son las referencias, con las que se puede comprobar que la solución funciona en otros clientes. También solemos realizar demos personalizadas o incluso workshops técnicos. E incluso tendríamos lo que llamamos Pruebas Piloto, que son instalaciones reales a pequeña escala y en el entorno del cliente. Estas se suelen alargar más en el tiempo y llevan costes asociados. Se podría escribir un artículo solamente hablando de estas herramientas de preventa…

El caso es que la irrupción de la tecnología RPA ha supuesto una auténtica revolución para los proyectos de transformación digital y es algo por lo que muchas empresas se interesan, ya que es una manera rápida y sencilla de empezar a automatizar tareas. Por poner un ejemplo, durante 2019 nosotros tuvimos una media de 2 a 3 nuevos contactos a la semana interesándose solamente por esta tecnología. Si suponemos una tendencia similar o mayor en nuestros competidores y si a esto añadimos que algunos fabricantes RPA cada vez tiene más distribuidores (algunas soluciones ofrecen trainings online gratuitos o versiones de software libre) se está creando un mercado en el que casi cualquiera puede venderte una solución RPA. Y además se está haciendo costumbre el realizar una POC para cada cliente interesado. Por eso hoy en día las palabras RPA y POC están más unidas que nunca. Y me pregunto por qué?

Personalmente pienso que está todo relacionado con los nuevos distribuidores que están apareciendo por todos lados. Como no tienen buenas referencias todavía, la POC es una buena manera de ganarse la confianza del cliente. En teoría es una tecnología fácil de implementar. Además, casi todos cobran por los servicios, con lo que tienen poco que perder y de paso se forman en la herramienta al implementar un proyecto. Esto lógicamente hace que algunas POCs no salgan bien, pero no importa mucho ya que hay otra esperando la semana próxima. Tengo que la impresión de que se vende más la POC que el producto final.

Esta forma de negocio hace que si a un posible cliente le gusta tu solución te acabe pidiendo una POC, porque se la han ofrecido otros.

Y no nos engañemos, cualquiera de las soluciones RPA más conocidas son capaces de automatizar una tarea específica. Costará más o menos trabajo, pero se podrá implementar. Entonces realmente son útiles las POCs de RPA?

Considerando que el informe de AIIM Emerging Technologies (2019) indica que solamente un 3% de las empresas que han conseguido escalar la tecnología RPA con 50 o más robots, es evidente que focalizarse solamente en hacer una POC de una tarea específica no da toda la visión. 

De hecho, la mayoría de las veces solamente queda automatizada esa misma tarea o alguna otra más. Y esto es debido a que la solución elegida no permite trabajar a nivel corporativo o el vendedor no tiene la experiencia para ayudar a montar un centro de excelencia o expandir la solución.

Por tanto mi conclusión sería que una Prueba de Concepto sobre una tarea concreta no siempre indica la idoneidad de una solución sino que también se debe tener en cuenta hasta dónde puede llegar el producto a nivel corporativo y quién lo implementa.

En el mundo de la captura documental los documentos se han dividido tradicionalmente en tres tipos; estructurados, semi estructurados y no estructurados.

Hace más de 20 años, los primeros programas de captura se centraban en capturar información de documentos estructurados, en los cuales se sabía en qué posición estaba cada uno de los datos. En aquella época, en la que el uso de páginas web no estaba todavía extendido, era habitual utilizar este tipo de formularios para comunicarse con las empresas y se consiguió automatizar miles de procesos de captura de este tipo (pedidos, encuestas, partes de trabajo, exámenes, etc.)

Después se empezó a automatizar la captura de documentos semi estructurados, en los cuales los datos varían de posición, pero se pueden crear reglas para encontrarlos. El proyecto típico era la captura de facturas de proveedores, en los que se conseguía capturar alrededor de un 70% de los datos automáticamente. Posteriormente se introdujo la técnica de aprendizaje automático de plantillas de proveedores, que ahora se anuncia como “Machine Learning”. Esta técnica hace que el software aprenda cómo es la factura de cada proveedor después de que el usuario haya indicado dónde están los datos. Una vez aprendidos los principales proveedores y combinando aprendizaje con el uso de reglas, se conseguía capturar más del 90% de los datos de las facturas. En los últimos 10 años hemos implementado cientos de proyectos de este tipo y hoy día seguimos ayudando a compañías que todavía no han automatizado su proceso de cuentas a pagar.

Y no ha sido hasta hace unos pocos años que se ha empezado a trabajar en la captura de documentos no estructurados, en los que no existen reglas a aplicar y en los que tampoco se puede utilizar técnicas de aprendizaje de plantillas porque no se suelen repetir documentos del mismo tipo (plantillas). Es el caso de la captura de datos de hipotecas, escrituras,  actas notariales o correos electrónicos que lleguen a una cuenta.

Para extraer información de estos documentos se han de utilizar técnicas de inteligencia artificial y, más específicamente, de Procesamiento de Lenguaje Natural (NLP en inglés). Existen muchos servicios y programas que usan NLP (MicroSoft, Google, etc.) pero la mayoría están focalizados en la extracción de etiquetas o atributos (por ejemplo, obtener todos los nombres que aparecen en un documento) y en análisis de sentimiento (el texto indica algo positivo o negativo). Además, sus bases de conocimiento están creadas con lenguaje natural (el lenguaje que hablamos normalmente), que no suele ser el lenguaje que se utiliza en documentos de negocio. Por ello es importante utilizar una herramienta que sea capaz de usar técnicas NLP para encontrar datos específicos de un documento (por ejemplo, si existen varios nombres en un documento, debe indicar quién es el Notario y quién el Compareciente). Las herramientas más generalistas no suelen servir para este propósito.

Para entender cómo funciona este tipo de soluciones, a continuación muestro un ejemplo de cómo se realiza la captura de datos de Escrituras. El proceso se divide en 3 partes:

• Aprendizaje, es la fase clave, en la cual se debe seleccionar una muestra de documentos significativa (o suficientemente grande) y enseñar al sistema dónde están los datos que buscamos. El motor de inteligencia artificial analiza los textos (técnica NLP), tanto los que contienen los datos a buscar como los que les rodean (contexto) para encontrar patrones y asignarles un peso.

El entrenamiento se realiza antes de entrar en producción, aunque siempre se puede ajustar posteriormente con nuevas muestras. Como resultado, el software creará una base de conocimiento conteniendo todo el análisis de patrones.

En este vídeo muestro cómo se realiza la fase de aprendizaje usando unas muestras de Escrituras como ejemplo:

• Reconocimiento. Ya en la fase de producción, lo primero que se realiza es el reconocimiento de los documentos. En este momento se aplica la base de conocimiento a cada documento para encontrar los patrones que puedan coincidir en cada uno de los datos. Además del dato en sí mismo, el software devuelve un porcentaje de confianza.

La fase de reconocimiento se suele ejecutar de manera autónoma y como un servicio invisible a los usuarios. Sin embargo, en este vídeo muestro cómo se realizaría manualmente y lo rápido que es:

• Validación. Tras el reconocimiento se realiza la Validación de aquellos documentos en los que hay alguna incidencia o algún campo no ha podido ser encontrado.

Es importante recordar que todo este tipo de soluciones de captura tiene como objetivo final la reducción del tiempo total del proceso. El objetivo nunca debe ser alcanzar un cierto porcentaje de reconocimiento. En otras entradas del blog ya he analizado más en detalle este tema, porque todavía hay gente que se centra solamente en los porcentajes de captura.

En este vídeo muestro los resultados del reconocimiento anterior aplicado a Escrituras. En una solución en producción el software solamente se parará en aquellos datos que tengan una incidencia a resolver por el usuario pero en este caso he ido parando en cada uno de los datos para que se pueda ver el resultado de la extracción:

Cada vez surgen más proyectos para capturar documentos no estructurados y pienso que será la tendencia en los próximos años. Espero seguir publicando más proyectos de éxito mostrando otros tipos de documento no estructurados.

¿Alguna vez habéis oído la expresión «llevar un escáner en el bolsillo»? Lo dispositivos móviles (teléfonos y tabletas) tienen muchísimas funciones útiles para el usuario y, entre ellas, hoy quiero destacar la posibilidad de capturar documentos.

Y cuando hablo de capturar un documento me refiero a obtener una imagen fiel del mismo y no me refiero a sacar una foto cualquiera. La imagen de un documento no debería tener ningún tipo de fondo, debería estar rotada correctamente y ser perfectamente legible. ¡Cuántas veces me he encontrado un repositorio documental lleno de fotos de DNIs girados, de mala calidad y en las que se ven manteles de fondo, mesas, dedos, etc! Esto no es un repositorio documental sino un repositorio de imágenes a las que no se le puede sacar mucho partido. Por ejemplo, no se les puede hacer OCR para extraer datos, no se puede comprobar si el documento es auténtico y no se pueden extraer elementos como la foto y la firma.

Quizás en nuestra vida personal no es algo que nos importe demasiado, pero en el mundo empresarial la gestión de la información es fundamental para el negocio. Y cuanto mayor calidad tenga un documento y más sencillo le sea a un cliente enviar documento, mejor y más rápidamente se podrá dar servicio a dicho cliente. Esto crea una clara ventaja competitiva y por ello vemos ejemplos de compañías que permiten a sus clientes enviar documentación con sus dispositivos móviles o habilitan a sus propios empleados (en sucursales, oficinas remotas o los que van por la calle) con aplicaciones móviles que facilitan el envío de documentos sin necesitar ningún otro aparato.

Para dar una idea de lo que se puede realizar con un teléfono móvil, he creado el siguiente vídeo, en el que muestro distintos escenarios en los que se captura un documento obteniendo una calidad tan buena que incluso se puede hacer OCR y extraer datos del mismo.

¿Tú también usas el escáner que llevas en el bolsillo?

Existe una tendencia en muchos comunicados sobre RPA a añadir las palabras “Inteligencia Artificial” (AI en inglés) en su mensaje, de tal manera que se podría pensar que un cierto proveedor de tecnología RPA incluye Inteligencia Artificial en sus productos.

Es cierto que ambas tecnologías se complementan bien y desde cualquier producto RPA se puede llamar fácilmente a un servicio externo de inteligencia artificial. Por ejemplo, ya existen múltiples robots que llaman a los servicios de Google Cloud Natural Language, IBM Watson o Microsoft Azure Text Analytics entre otras opciones.

Sin embargo, lo que realmente despertaba mi curiosidad era saber si los productos de RPA incluían o no algún tipo de inteligencia artificial por sí mismos (sin llamar a herramientas externas). Así que, después de leer multitud de artículos y visionar otros tantos vídeos de demonstraciones, he intentado separar la paja del grano e identificar lo que realmente incluyen los principales proveedores de RPA en sus productos.

Pero antes de nada, es necesario entender correctamente algunos términos básicos que se utilizan en este contexto.

Inteligencia Artificial

El diccionario de Oxford la define como:

Programa de computación diseñado para realizar determinadas operaciones que se consideran propias de la inteligencia humana.

Una de las herramientas más importantes que utiliza la Inteligencia Artificial para resolver estos problemas es Machine Learning (Auto Aprendizaje), que es una técnica por la cual los sistemas aprenden algo automáticamente a medida que se les va suministrando información. Para aprender se usan distintos métodos; probabilísticos, clasificadores (máquinas de vectores, vecino más cercano, árboles de decisión…), clustering, regresión, etc.

Otro término que suele aparecer es el de Computer Vision (Visión Artificial), que es una disciplina de la Inteligencia Artificial cuyo objetivo es que un sistema entienda y clasifique imágenes como lo haría una persona. Para ello se puede utilizar Machine Learning u otro tipo de técnicas.

De forma parecida, el Procesamiento de Lenguaje Natural (NLP en inglés), es otra disciplina de la Inteligencia Artificial cuyo objetivo es que un sistema entienda y procese el lenguaje humano. También se utilizan técnicas de Machine Learning para identificar la estructura, idioma o datos concretos. En este punto cabe destacar que solamente el 10% de los documentos de una empresa contienen lenguaje natural. La mayoría contienen un lenguaje más acotado según el tipo de negocio.

Como no puedo analizar todas las soluciones RPA del mercado, me he centrado en las más destacadas y empiezo por Kofax, que es la que mejor conozco.

Kofax

Kofax es especialista en automatizar procesos que conllevan la gestión de información contenida en documentos. Sus soluciones incluyen RPA, BPM, Captura de información multicanal, Firma electrónica, CCM y BI (Business Intelligence). Su solución de RPA incluye funcionalidad para clasificar todo tipo de documentos y extraer datos de los mismos. Esto permite a los robots tomar decisiones en base al contenido de la documentación que manejan. Kofax lleva usando Inteligencia Artificial en sus productos desde hace más de 15 años pero nunca hizo publicidad sobre ello.

La clasificación utiliza Machine Learning de tal forma que al producto se le dan muestras de un tipo documental y automáticamente genera una base de conocimiento en función de las similitudes que encuentra entre las muestras. Se hace lo mismo con cada tipo de documento. Como ejemplo, se puede utilizar esta función para clasificar todos los correos electrónicos recibidos y enrutarlos automáticamente al departamento adecuado (contabilidad, atención al cliente, soporte, etc.).

La extracción de datos también utiliza Machine Learning para saber dónde están los datos a extraer de cada documento y aprende a medida que pasa el tiempo. La mayor parte de documentación que trata Kofax es empresarial pero su función más avanzada incluye tecnología NLP para tratar lenguaje natural, extrayendo información en base a su contexto. En los proyectos más sencillos se extrae información de documentos estructurados como facturas, pedidos, dnis, contratos, etc y en los más complejos se trabaja con documentos no estructurados como hipotecas, escrituras, actas de reunión, etc.

Además de Machine Learning, Kofax dispone de un potente motor de reglas para complementar la clasificación y extracción de datos.

Para el control de la pantalla, los robots de Kofax tienen la opción de utilizar Intelligent Screen Automation (ISA), una técnica de Computer Vision que consiste en realizar una identificación de todos los objetos de la pantalla, así como un reconocimiento de todas las palabras que aparecen (OCR). Esto permite al robot moverse por la pantalla en base a un objeto (menú, botón, cuadro de texto, imagen, etc.) y a las palabras que lo rodean y no depender de la posición fija de cada objeto. Esto da mucha flexibilidad en producción, ya que no es obligatorio que las pantallas siempre sean exactamente iguales, con la misma resolución y aspecto. La identificación de los distintos tipos de objeto en pantalla se ha realizado utilizando técnicas de Machine Learning, enseñando al software cientos de pantallas de aplicaciones de ejemplo.

Blue Prism

Blue Prism fue uno de los pioneros de las soluciones RPA y, aunque va perdiendo mercado, sigue siendo una de las referencias del sector. Se pueden encontrar cientos de artículos de Blue Prism llamando a todo tipo de servicios externos de Inteligencia Artificial y el producto está preparado para comunicarse con los más conocidos (Google, Microsoft, etc.). Sin embargo, no he encontrado ninguna referencia que incluya algún tipo de funcionalidad de AI dentro del producto.

Recientemente Blue Prism anunciado la creación de un nuevo laboratorio dedicado a embeber capacidades de Inteligencia Artificial dentro de su producto.

https://www.blueprism.com/news/blue-prism-expands-r-d-capabilities-adding-dedicated-ai-labs-and-outlines-roadmap-for-embedded-ai-capabilities

En el artículo se destaca que la clave será incluir la posibilidad de entender datos de documentos en cualquier formato y utilizar Computer Vision para mejorar el diseño de robots cuando interactúan con el entorno, siguiendo las ideas mencionadas anteriormente.

UiPath

UiPath es una de las compañías que más ha crecido hasta el punto que muchos analistas (p.e. Forrester o Gartner) lo consideraron líder del sector durante el 2018. Merece la pena recordar que los analistas no valoran solamente la funcionalidad de los productos, que es lo que más me interesa personalmente, sino también parámetros empresariales como cobertura de mercado; industrias y geografías, número de referencias, estrategia, modelo comercial, etc.

En cuanto a funcionalidad, como el resto de proveedores, el producto se integra con prácticamente cualquier herramienta de Inteligencia Artificial externa. Además, hace unas semanas UiPath ha anunciado la posibilidad de automatizar pantallas utilizando Computer Vision: https://twitter.com/uipath/status/1086231426503106560. Esto permite a los robots no basarse en posiciones fijas en la pantalla.

Desafortunadamente UiPath utiliza herramientas externas para poder entender la información contenida en documentos y no parece que tenga planes en este sentido. Es el único en el que no he podido encontrar ningún plan para añadir funciones que permitan entender  documentación.

Automation Anywhere

Automation Anywhere es el tercer gran referente del sector RPA y seguramente el líder en el mercado americano. Ofrece IQ Bot, que es una tecnología que permite extraer información de documentos utilizando técnicas de Inteligencia Artificial: https://www.automationanywhere.com/images/products/IQBotBrochure.pdf

Los mensajes que lanzan llevan mucha parte de marketing y es difícil saber exactamente qué técnicas utilizan, pero por los vídeos que he visto diría que usan Machine Learning para aprender dónde está la información en los documentos.

Sin embargo la funcionalidad parece bastante básica. No he visto ejemplos con documentos complejos (la mayoría de veces se capturan facturas, que es algo ya solucionado hace muchos años) y no parece que tengan posibilidades de capturar datos de documentos no estructurados (hipotecas, contratos, etc.). Tampoco he visto que se pueda complementar el aprendizaje con reglas de diseño (búsqueda por palabras clave, formatos o relación entre datos) o incluso crear plantillas fijas. Y no tengo muy claro si el Aprendizaje se ha de realizar antes de la puesta en marcha o tiene la posibilidad de hacer un aprendizaje online (lo ideal es disponer de ambas opciones).

Workfusion

La propuesta de Workfusion es muy similar a la de Kofax en el sentido de que además de un RPA tradicional la solución incluye Machine Learning para capturar información de documentos no estructurados, un gestor de workflow y herramientas de Análitica y Reporting. Workfusion es una empresa creada hace unos pocos años y que viene fundamentalmente del mundo de la inteligencia artificial.

Casi todas sus noticias públicas o vídeos tienen un alto componente de marketing. Pero estos dos artículos dan una buena idea de cómo funciona su solución principal (Workfusion SPA):

https://blog.workfusion.com/8-steps-to-supercharging-rpa-7b0982e4c7d3

https://blog.workfusion.com/5-top-questions-email-intake-processing-418ba7905e18

La idea de Workfusion sigue la línea de utilizar Machine Learning (con distintos algoritmos) para poder extraer información de documentos (estructurados y no estructurados) y que el robot pueda realizar una tarea u otra dependiendo de esta información. Los pasos utilizados para el aprendizaje son los conocidos (recopilación de muestras significativas, apoyo de un usuario para enseñar dónde están los datos y generación de la base de conocimiento). De lo que adolece la solución, desde mi punto de vista, es de complementar toda la parte de Inteligencia Artificial con un motor de reglas para poder implementar distintos casos uso que se presentan habitualmente en este tipo de proyectos.

Por otro lado, me ha sorprendido que, siendo especialistas en el mundo de la Inteligencia Artificial, todas sus referencias públicas hablan de capturar documentos que son muy sencillos. Como ejemplo, Workfusion realiza una competición (hackathon) entre sus partners para llevar su tecnología al máximo nivel y resulta que las dos ediciones realizadas se han basado en capturar información de facturas. Como ya he comentado en alguna ocasión, la captura de datos de facturas está solucionada desde hace más de 15 años. Esperaba haber encontrado algún caso de uso más complejo.

Otros

La mayoría de los proveedores de RPA están trabajando en sistemas que sean capaces de analizar el trabajo que hacen los usuarios para construir los robots automáticamente (o más fácilmente). Al principio la idea era bastante sencilla y se realizaba una grabación de una parte del trabajo del usuario y el robot se construía reproduciendo las tareas grabadas. Esto está muy bien para hacer una demonstración pero no es muy aplicable en producción porque los robots deben aprender a trabajar con las excepciones, por lo que se acaba necesitando una configuración manual.

Por ello ya existe alguna empresa hoy en día que está intentando aplicar Inteligencia Artificial a este fase de diseño, de tal forma que tras observar a un usuario durante días, el software determinará automáticamente todas decisiones que va tomando en función de los datos que aparecen en pantalla e implementará el robot teniendo en cuenta todas estas posibilidades. Suena un poco a ciencia ficción y parece ser que hoy en día esta solución funciona muy bien para crear robots que ejecuten lo que se llama el “happy path” o la tarea que el usuario realiza más frecuentemente pero sus diseñadores nos cuentan que todavía falta bastante para que reconozca correctamente las excepciones.

Conclusiones

No nos engañemos, los productos RPA tradicionales, que solamente imitan los movimientos de un usuario en un PC, no requieren tecnología de la NASA o programación muy compleja. Si se quiere elegir uno hay que tener muy en cuenta su arquitectura y escalabilidad. Y, sobre todo, lo que les proporciona un valor añadido es la posibilidad de entender la información que procesan porque permite automatizar muchos más procesos. La Inteligencia Artificial ayuda en esta parte y por eso vemos cada vez más publicidad en este sentido.

Este es el camino que están siguiendo los proveedores de RPA aunque, como hemos podido ver, a día de hoy existen diferencias significativas entre ellos. Mientras que Kofax lleva muchos años capturando información de documentos otros acaban de empezar, como Workfusion y Automation Anywhere, algunos ni siquiera han comenzado (Blue Prism) y otros se apoyan en herramientas de terceros (UiPath), lo que tiene muchas desventajas al depender de otras compañías (consultores distintos, mantenimientos distintos, licencias distintas, etc.)

Los primeros que llegaron al mercado son los que lo han copado, pero ya sabemos que, en tecnología, después de la fase inicial de desarrollo del negocio llega la fase de competencia (en la que estamos ahora, con soluciones apareciendo por todos lados) y posteriormente llega la fase de dominación con una o dos soluciones como líderes indiscutibles (que no siempre son las que empezaron). Nos quedan por ver unos años muy interesantes en el mundo RPA.

Todavía sigo viendo proyectos en los que se mide el éxito de un sistema de captura de datos en base al porcentaje de acierto del OCR. Incluso en algunas pruebas de concepto el cliente todavía tiende a comparar las distintas soluciones en función de los porcentajes de extracción obtenidos.

Supongo que en parte ha sido culpa nuestra, de los proveedores de tecnología, que en el pasado nos centrábamos mucho en este parámetro y siempre intentábamos mejorarlo lo máximo posible en las implementaciones. Este año Kofax sacó una publicación en torno a este tema: The truth about ocr accuracy, que quiero difundir entre todos los que estén interesados en capturar datos de documentos.

La cuestión básica es que el porcentaje de captura (o de OCR) no es un parámetro significativo para el negocio. Por ejemplo, ¿qué decisión puede tomar un directivo si le contamos que una solución tiene un porcentaje de captura del 80% y otra solución tiene un porcentaje del 70%? Pues posiblemente ninguna! ¿Cómo podría entender la repercusión de cualquiera de ellas en su negocio? o cómo calcularía un posible retorno de la inversión? No podría! Y lo  más probable es que solicite más información para entender las implicaciones que tiene el proyecto en su negocio.

Sería demasiado simple pensar que la primera solución es mejor solamente con este dato. ¿Qué ocurriría si esta primera solución tiene menos funciones para facilitar la gestión de las excepciones (los datos que no han podido ser capturados)? Supongamos que con la primera solución se tarda el doble de tiempo en solventar cada excepción. Con esta hipótesis podría ser más rápido arreglar el 30% de excepciones de la segunda solución que el 20% de excepciones de la primera. Es decir, la segunda solución sería más efectiva de cara al negocio, ofreciendo mayores beneficios al cliente. De hecho, cuanto mayor sea el volumen de documentos a procesar mayor será el beneficio en comparación con la primera solución. En la publicación mencionada anteriormente se describen técnicas que facilitan la gestión de excepciones.

Otro factor que puede alterar nuestra percepción es el umbral de reconocimiento (probabilidad límite para aceptar un dato como correcto). Es un número (entre 1 y 100) que se define manualmente. Normalmente sólo se aceptan datos con un umbral de reconocimiento alto (por ejemplo, mayor del 80%). Si la primera solución ha bajado mucho este umbral (pongamos que al 25%) es posible que acierte alguna vez y eso aumenta su porcentaje de acierto pero ya no te puedes fiar de los datos que devuelve porque muchos serán incorrectos. Por ello toda la información se deberá confirmar manualmente (hay que validarlo todo porque no se sabe cuándo acertará).

Si la segunda solución ha puesto un umbral más alto, garantiza una mejor calidad de la información extraída pero al rechazar más datos se penalizará su porcentaje de acierto. La paradoja es que ambos podrían estar devolviendo exactamente los mismos datos pero la segunda solución parecería peor. En ambos casos el usuario deberá gestionar el dato manualmente (o por validación o por rechazo), por lo que vuelve a ser más relevante el tiempo que necesita el empleado en gestionar las excepciones.

En resumen, el porcentaje de OCR es un dato indicativo pero no suficiente. Lo que realmente interesa conocer es el tiempo total que se tarda en procesar un documento de media, desde el principio hasta el final. Este tiempo dependerá tanto del porcentaje de OCR como de la rapidez en gestionar las excepciones. Con esta información sí se pueden tomar decisiones. Por ejemplo, si una solución me permite procesar documentos en 70% menos tiempo que hoy en día manualmente, muy posiblemente me interese implementarla. Si la solución A me permite procesar 1000 documentos al día y la solución B procesa 800 documentos al día, ya puedo calcular cual me va a ofrecer un mejor retorno de la inversión.

Si aun así alguien está solamente interesado en el porcentaje de OCR mi recomendación sería que eligiera simplemente un motor de OCR (los hay incluso gratuitos) y no una solución completa de captura.

Finalmente quisiera resaltar que en la implementación moderna de este tipo de soluciones, donde se tratan documentos cada vez más complejos, el porcentaje de OCR es cada vez menos relevante. Tradicionalmente, trabajando con documentos más estructurados, se han utilizado sistemas basados en reglas para capturar información. Íbamos añadiendo más y más reglas para ir mejorando dicho porcentaje, pero cada vez se hacía más complicado porque cada nueva regla afectaba a las anteriores, por lo que la mejora acaba estancándose en algún momento. Hoy en día los proyectos capturan documentos más complejos como hipotecas, escrituras, actas, etc. y se basan mayoritariamente en técnicas de Machine Learning. Es decir, se deja que el sistema vaya aprendiendo solo a medida que procesa documentación. No se implementan reglas. El problema de esta técnica de inteligencia artificial es que necesita muchas muestras para aprender bien. Como no se suelen tener tantos ejemplos, los proyectos comienzan con porcentajes más bajos de reconocimiento y todo el foco de la implementación se pone en el diseño de formularios eficaces para la corrección e introducción de datos. El retorno de la inversión no es tan rápido pero el coste de procesar manualmente estos documentos complejos es muy alto y con el paso del tiempo (y documentos) la solución va aprendiendo sin parar y el ahorro acaba siendo significativo.

En nuestras oficinas, como en la vida misma, podemos encontrar distintos tipos de personas; unos más simpáticos, otros más preparados, unos que comunican mejor, otros que trabajan largas horas, algunos con más experiencia, etc. Estaremos de acuerdo en que la diversidad enriquece a las empresas y lo lógico es poner en cada puesto el perfil que más se adecua al mismo.

Por otro lado observo que la expansión de la tecnología RPA (Robotic Process Automation) en la gran empresa está llevando a crear departamentos de robótica, a veces llamados factorías RPA o centros de automatización, que suelen crear entre 30 y 50 trabajadores virtuales (robots de software) al año. Algunos incluso más.

Siguiendo el esquema tradicional de compra de software corporativo, estas empresas seleccionaron una única herramienta RPA, del mismo modo que se suele eligir un solo ERP, un único CRM o una única aplicación de gestión de contenido (ECM). Por tanto, puede ocurrir y ocurre, que si esta herramienta RPA no es lo suficientemente flexible, los trabajadores virtuales acaban siendo todos iguales y realizando tareas muy parecidas, dejando de automatizar otras que podrían ser más rentables.

Algunos que ya tienen trabajadores virtuales con buena reputación y que automatizan bien procesos básicos se encuentran atados de manos cuando quieren llegar más allá. Entiendo que estas empresas necesitan añadir herramientas que sean capaces de crear trabajadores virtuales con más cualidades.

Por ejemplo, que sean capaces de acceder a aplicaciones sin necesidad de conectarse a un PC o Escritorio. Este es el caso de la Automatización de la Web (“Web Automation”), en la que los trabajadores virtuales pueden acceder a páginas web, aplicaciones con interfaz web, ficheros Excel, ficheros XML o Terminal Server directamente en memoria sin necesidad de abrir navegadores o conectarse a otros equipos. Esto supone un ahorro en infraestructura enorme. Como muestra, el uso de 20 trabajadores virtuales realizando este tipo de tareas supone un ahorro en infraestructura de 20 máquinas o escritorios. De hecho, conozco dos casos que tienen más de 5.000 trabajadores virtuales de esta clase. Pienso que es un tipo de robot necesario en toda factoría RPA.

Otra cualidad muy valorada es la posibilidad de clasificar documentación y extraer datos de la misma para tomar una decisión y continuar con un proceso determinado en base a dicha decisión. Es lo que se denomina «Intelligent Process Automation». Es verdad que siempre se puede comprar una aplicación externa a la que nuestro robot pueda llamar, pero tiene más ventajas usar una herramienta que ya la lleve integrada porque permite crecer más rápidamente y a menor coste al evitar mantenimientos dispares, actualizaciones independientes y no disponer de un roadmap conjunto y arquitectura unificada. Este tipo de robots serán la base de la segunda ola de RPA, que llegará una vez automatizados los procesos básicos. También aconsejaría contar con este tipo de robot en toda factoría RPA.

Otro punto a tener en cuenta es la forma en la que se pueden llamar a nuestros trabajadores virtuales. Lo ideal es que se puedan llamar desde cualquier aplicación directamente, como servicio web, como un proceso programado cada cierto tiempo o como un proceso batch (es lo que se denomina “Unattended Automation”) y que además se puedan llamar manualmente seleccionándolo de una lista, incluso con una combinación de teclas o cuando ocurre algún evento en nuestro escritorio (“Attended Automation”). La mayoría de herramientas RPA cuentan con una u otra forma de ser llamadas pero es importante que cuenten con las más posibles. Personalmente creo que el poder desplegar un robot como servicio web tiene muchas ventajas. Además siempre tendrán superioridad las herramientas que despliegan sus trabajadores virtuales en servidor y que pueden ser llamados desde cualquier puesto sin necesidad de instalarlos localmente.

En resumen, creo que debemos plantearnos si con la tecnología RPA estamos únicamente comprando software o estamos contratando trabajadores (virtuales). En este último caso aconsejaría buscar trabajadores (virtuales) que sean capaces de adoptar múltiples perfiles laborales. Y si nos faltara un perfil determinado lo mejor es contratarlo y añadirlo a la plantilla, igual que haríamos con cualquier otro empleado.

A principios de año, participando en una mesa redonda sobre Transformación Digital junto con CIOs de distintos sectores, alguien preguntó quién debía liderar los proyectos en los que alguna unidad de negocio quiere adquirir un software. El debate fue muy interesante con razonamientos de todo tipo. La mayoría afirmaron que en su empresa el software lo seleccionan siempre ellos. Solamente unos pocos dejan que sea el usuario quien haga la selección con el apoyo del departamento de TI (para asegurar la integración con el resto de sistemas, control del hardware y cumplimiento de estándares internos).

Un par de meses después, en una presentación sobre los beneficios de la tecnología RPA, de nuevo uno de los asistentes me preguntó quién debería liderar este tipo de proyectos, si el departamento de TI o el propio usuario y se inició un pequeño coloquio similar al anterior. Compartí mi experiencia con esta tecnología específica, para la que la mayoría de mis clientes han creado un departamento o equipo RPA formado mayoritariamente por usuarios avanzados que son los que crean los robots de software.

Pero esto hizo que cogiera interés en el tema y reflexionara sobre los siguientes hechos:

• En la metodología de venta de mi empresa se hace especial hincapié en involucrar siempre al usuario, ya que es quien realmente tiene el problema, entiende mejor la funcionalidad del software y sabe hasta dónde puede ayudarle, así como puede evaluar cómo la funcionalidad futura (roadmap del producto) se ajustaría a su trabajo en unos años. En muchas ocasiones recibimos un documento de requisitos (RFI o RFP) en los cuales las cuestiones sobre funcionalidad son menores que las de integración, bases de datos y seguridad.
• Algunos de mis principales clientes, grandes multinacionales con las que tengo una relación continua, ya hace tiempo que decidieron descentralizar la compra de software, dejando que sean las unidades de negocio quienes determinen qué aplicaciones necesitan.
• Una encuesta de Harvard Business Review (2015) sobre las perspectivas que tienen los CEOs sobre sus departamentos de TI y sus CIOs reveló que más de la mitad de los CEOs piensan que sus CIOs no saben aplicar bien la tecnología a un negocio cambiante y solamente un 25% piensan que sus CIOs rinden por encima de otros ejecutivos.
• Los directores de los distintos departamentos entienden mucho más de tecnología que hace diez años y están perfectamente preparados para hablar con los proveedores de tecnología. También vemos que cada vez más CEOs se involucran en temas tecnológicos, siendo estos los que mejor suelen respaldar la transformación digital dentro de sus empresas.
• Los departamentos de TI se han pasado la última década realizando costosas y largas implementaciones de sistemas de backoffice, como ERPs, ECMs, CRMs, etc. y además de ser vistos como un centro de coste, los usuarios tienden a pensar que la única misión de IT es que todos estos sistemas funcionen día a día y no se caigan.

Con este panorama, en mi cabeza rondaba la incertidumbre de cuál era realmente el papel de las TI dentro de la empresa y cómo podría apoyarles desde el punto de vista de un proveedor de tecnología. Y la respuesta me la dió Jon Mancini, cuando este verano hice el curso “Meeting the Challenge of Digital Transformation” (https://es.linkedin.com/learning/meeting-the-challenge-of-digital-transformation?trk=seo_pp_d_cymbii_title_m015_learning). En una parte del curso Mancini explica que los CIOs y sus departamentos de TI deben de transformarse porque durante muchos años solamente se han dedicado a una de las letras que les da sentido: la “T” de Tecnología, involucrándose en continuos proyectos de instalación de aplicaciones y sistemas, olvidándose completamente de la otra letra, la “I” de Información.

Como premisa fundamental, el CIO y su departamento de TI son responsables de que la información dentro de una empresa esté disponible en el sitio en que se necesite y en el momento en que se necesite. Desde mi punto de vista, esto le da una nueva perspectiva al departamento de TI, que le llevaría a liderar de manera proactiva todos los proyectos en los que haya involucrada información, pero ahora no desde el punto de vista de la compatibilidad, seguridad o estándares, sino desde el punto de vista de la información, que en definitiva es el mismo punto de vista que el del usuario.

Mancini incluso piensa que se creará un nuevo perfil informático, que será el Técnico de Información y cuya misión será entender y preocuparse únicamente por los flujos de información dentro de la empresa. Entiendo que esta es una buena manera de involucrar a las TI dentro del negocio y una buena forma de empezar un proceso de transformación digital interno.

Sospecho que durante los próximos años vamos a ver una mezcla en la que muchos seguirán centrándose en las aplicaciones, otros continuarán dando más poder de decisión a sus usuarios y unos pocos tomarán la sartén por el mango y empezarán a centrarse en los flujos de información sin que ni siquiera se lo hayan pedido otros departamentos. Seguramente estos últimos acabarán teniendo ventaja competitiva sobre el resto. Lo que tengo claro es que la próxima vez que surja la pregunta, el debate se va a alargar bastante más….

Comienzo este blog con el propósito de divertirme, compartir información y aprender. Llevo muchos años trabajando en distintas tecnologías que habilitan la transformación digital en la empresa y quisiera compartir con vosotros mi visión sobre las soluciones que se están implantando, tendencias y los hechos significativos que veo en el día a día.

Hablaré sobre RPA, que es una de las tecnologías más de moda últimamente, y también sobre Extracción Automática de Datos, que aun siendo un mercado muy maduro todavía tiene su demanda, Firma Electrónica, cuya adopción crece sin parar, Composición de Documentos, otra tecnología en fase de madurez, Captura desde dispositivos móviles, que por ahora no ha tenido gran difusión salvo en la banca, BPM y en general sobre el papel que desempeñan los departamentos de Tecnologías de Información hoy en día.

Como entiendo que mis ideas son particulares y no siempre serán correctas, agradeceré los comentarios que hagan abrir mi perspectiva sobre cualquiera de los temas publicados. Por otro lado, no tengo intención de hablar ni comparar productos o marcas particulares sino de tecnología en general.

El crear toda la infraestructura para llegar a escribir esta primera entrada ya ha sido todo un aprendizaje para mí. En cuanto a ti, si el blog te parece interesante puedes subscribirte y compartirlo con otros colegas. Y no olvides que tus comentarios son importantes.