Integración de la inteligencia artificial

Qué significa integrar la IA y qué no significa

En resumen: Detrás de la misma palabra se esconden tres realidades muy distintas: usar un asistente de consumo, activar funciones de IA dentro de una herramienta ya instalada, o encargar la construcción de un agente conectado a sus datos y a sus procesos.

La primera realidad es el uso de un asistente de consumo. Una persona abre una interfaz de conversación, formula su pregunta y copia el resultado en su documento. Nada está conectado al sistema de información: la herramienta solo conoce de la empresa lo que se le escribe en cada intercambio. Es un punto de entrada natural y tiene una virtud real, la de mostrar rápidamente, sobre textos reales del oficio, qué hace bien el modelo y qué falla. Es también la etapa en la que los usos se extienden sin reglas, cada cual eligiendo su herramienta y lo que acepta depositar en ella.

La segunda es la activación de funciones de IA dentro de herramientas que ya se utilizan: un gestor de correo que resume una conversación, un programa de gestión comercial que redacta un primer borrador de seguimiento, un procesador de textos que reformula un párrafo. Aquí el modelo ve los datos presentes en la herramienta, sin que haya que desarrollar nada. El trabajo pasa a ser de decisión y de configuración: qué funciones abrir, a quién, sobre qué datos y con qué validación antes de que un contenido salga al exterior.

La tercera es la construcción de un agente adaptado a un proceso concreto. Un asistente que lee las solicitudes entrantes, las clasifica según sus propias categorías, recupera la información correspondiente en sus documentos y prepara una respuesta que una persona revisa antes de enviarla. Es aquí donde se habla realmente de integración, porque hay que describir el proceso, distinguir lo que se vuelve automático de lo que sigue siendo una decisión humana y conectar el modelo con fuentes de datos identificadas.

Lo que el término no abarca merece decirse con la misma claridad. Integrar la IA no es comprar un producto que volvería inteligente a la empresa en su lugar. Tampoco es un proyecto puramente informático: las mejoras que se observan proceden de un cambio en la manera de hacer una tarea, es decir, de un trabajo sobre el proceso tanto como sobre la herramienta. Y no es una decisión única e irreversible, sino una sucesión de pequeñas elecciones revocables, lo cual resulta más bien tranquilizador, siempre que se tomen de forma consciente y no por omisión.

Cómo funciona un modelo de lenguaje conectado a sus datos

En resumen: Un modelo de lenguaje predice la continuación de un texto a partir de lo que se le da a leer. Toda la ingeniería de una integración consiste en proporcionarle el material adecuado —instrucciones, extractos de sus documentos, herramientas que puede invocar— en el momento adecuado.

Un modelo de lenguaje se entrena para predecir lo que viene después de un texto. De ese mecanismo se derivan tanto sus fortalezas como sus debilidades. Es notable a la hora de reformular, clasificar, resumir, extraer una información de un documento, traducir o producir una primera versión de un escrito. En cambio, no tiene ningún conocimiento verificado de sus expedientes y nada en su funcionamiento le obliga a señalar que ignora una respuesta: a falta de saber, produce aquello que más se parece a una respuesta. Ese es el origen de lo que se denomina alucinaciones, y es una propiedad del procedimiento, no un defecto pasajero.

Lo que se le da a leer se llama contexto. Contiene la instrucción, a menudo denominada prompt, y todo lo que se le añade: un extracto de un procedimiento, el contenido de un documento, el historial del intercambio en curso. Ese contexto tiene un tamaño máximo y, sobre todo, la respuesta se degrada cuando se lo recarga. Buena parte del trabajo de integración consiste, por tanto, en seleccionar automáticamente los elementos pertinentes en lugar de enviarlo todo, y en redactar una instrucción estable que describa el papel esperado, el formato de salida y la conducta que debe seguirse en caso de duda.

Conectar un modelo con los datos de la empresa suele hacerse mediante una búsqueda documental. Los documentos se dividen en fragmentos, se indexan por su sentido más que por las palabras exactas y, en cada pregunta, se recuperan los fragmentos más cercanos al tema y se colocan en el contexto. El modelo responde a partir de esos extractos y puede indicar de qué documento proceden. La ventaja práctica es decisiva: cuando cambia un procedimiento, basta con reindexar el documento, sin reentrenar nada. La contrapartida es igual de real: si la documentación interna está obsoleta o es contradictoria, el asistente reproducirá fielmente esas contradicciones.

Un modelo también puede invocar herramientas. En lugar de inventar un número de pedido, activa una función que consulta su base de datos y le devuelve el valor real. Ese mecanismo separa al asistente que conversa del asistente que actúa: consultar una agenda, crear una ficha, preparar un envío. Cada herramienta debe describirse con precisión y la regla de prudencia es sencilla: una acción que lee puede seguir siendo automática, mientras que una acción que escribe, compromete o envía merece una validación humana explícita.

Queda la cuestión de los permisos de acceso, que a menudo se descubre demasiado tarde. Un asistente conectado a un espacio de archivos ve exactamente lo que ve la cuenta con la que se le conectó. Si los permisos internos son aproximados, el asistente los pondrá a la vista: alguien obtendrá con una sola pregunta un contenido que nunca habría encontrado navegando por las carpetas. Cartografiar los accesos antes de conectar nada forma parte del trabajo mismo y no de los preliminares opcionales.

Cómo se desarrolla un proyecto de integración

En resumen: El orden importa más que la velocidad: comprender las tareas reales, elegir un caso de uso estrecho y verificable, elegir las herramientas, implantar con revisión humana, formar a los equipos y medir antes de decidir ampliar.

Todo empieza por un inventario de tareas, no por una demostración de herramienta. Se observa lo que hacen realmente los equipos, se anota lo que es repetitivo, lo que es esencialmente textual, lo que sigue reglas estables y lo que queda bloqueado a la espera de una persona. Los buenos candidatos se parecen de un oficio a otro: una tarea frecuente, escrita, de la que se sabe describir cómo es una buena respuesta y cuyo error puede corregirse sin consecuencias graves. Este encuadre produce un efecto secundario útil: saca a la luz rigideces que no necesitaban ninguna tecnología para corregirse.

Llega después la elección de las herramientas. Se decide sobre tres criterios mucho más que sobre el rendimiento anunciado: qué ocurre con el dato transmitido y dónde se procesa, la capacidad de la herramienta para conectarse con lo que ya utiliza y la posibilidad de abandonarla sin tener que reconstruirlo todo. La respuesta menos espectacular —activar una función ya incluida en una herramienta instalada— suele ser la más razonable para un primer caso de uso, porque reduce el número de cosas nuevas que deben funcionar al mismo tiempo.

La implantación se hace sobre un perímetro real pero restringido, con una persona que revisa sistemáticamente los resultados. Esa revisión no es una muestra de desconfianza: es la que produce los ejemplos necesarios para corregir. Se redactan las instrucciones, se observan los casos en los que la respuesta se descarrila, se precisa la consigna y se vuelve a empezar. El resultado de ese ciclo —una consigna escrita, ejemplos de buenas y malas respuestas, una lista de casos que no deben tratarse automáticamente— constituye una parte importante del valor del proyecto.

La formación de los equipos es la parte más subestimada. No se trata de aprender a hacer clic, sino de saber qué confiar al modelo y qué no confiarle nunca, cómo formular una petición útil, cómo reconocer una respuesta verosímil pero falsa y a quién señalar un comportamiento anómalo. Un equipo que no ha tenido esa conversación caerá en uno de los dos extremos: ignorar la herramienta por completo o confiar en ella sin releer. Ambos salen caros, el segundo de forma más discreta.

La medición, por último, se prepara antes de empezar; de lo contrario no existirá. Se anota cómo transcurre la tarea hoy: cuántas idas y venidas hacen falta, qué proporción de expedientes hay que rehacer, dónde se acumula la espera, cómo lo viven las personas implicadas. Tras la implantación se compara con los mismos indicadores. Esa comparación sirve tanto para decidir ampliar como para decidir detenerse, y un caso de uso abandonado por buenas razones es un resultado, no un fracaso.

Los errores que aparecen con más frecuencia

En resumen: Los fracasos se parecen entre sí: se automatiza un proceso que ya cojeaba, se transmiten datos sin saber adónde van, se confunde una demostración lograda con una puesta en producción y se retira demasiado pronto la verificación humana.

El primer error es automatizar un proceso que funciona mal. La automatización no corrige un encadenamiento de etapas incoherente, simplemente lo vuelve más rápido y más difícil de observar. Si existe una validación porque nadie se atreve a suprimirla, si una información se vuelve a teclear porque dos herramientas no se comunican, la cuestión que hay que resolver primero no es técnica. Una integración lograda empieza a menudo por eliminar unas cuantas etapas que se han vuelto inútiles.

El segundo se refiere a la confidencialidad de los datos transmitidos. Enviar un texto a un modelo significa confiarlo a un servicio ajeno cuyas reglas conviene conocer: si el contenido se conserva, si sirve para entrenar futuros modelos, quién puede acceder a él, dónde se procesa y cómo se obtiene su supresión. Esas reglas varían de una oferta a otra dentro de un mismo proveedor, y las ofertas destinadas a empresas no suelen contemplar los mismos usos que las versiones de consumo. Esta comprobación debe hacerse antes de la primera prueba, no después del primer incidente.

El tercero consiste en confundir demostración y puesta en producción. Una demostración se hace con ejemplos elegidos, en un orden elegido, por alguien que sabe cómo formular la petición. La producción son los casos mal redactados, los archivos adjuntos ilegibles, las situaciones que no encajan en ninguna categoría prevista y las personas que no tienen tiempo de reformular. Un caso de uso solo se juzga con datos reales, incluidos los más desagradables, y hay que decidir explícitamente qué hace el sistema cuando no sabe responder.

El cuarto es la desaparición de la verificación humana. Rara vez desaparece por decisión: se erosiona, porque las respuestas son buenas y la revisión se convierte en un trámite. Ese momento es precisamente el peligroso, porque una respuesta falsa se formula con el mismo aplomo que una correcta. Es preferible conservar una verificación proporcionada al riesgo: sistemática para lo que sale de la empresa o compromete un contrato, aligerada pero real para el resto, con un medio sencillo de señalar una respuesta dudosa.

El quinto, más humano, es imponer la herramienta sin explicar la intención. Cuando nadie dice qué se espera, cada cual supone lo peor, y el temor a volverse reemplazable produce un rechazo silencioso: la herramienta se abre cuando el responsable mira y se cierra después. Anunciar con claridad qué tareas se persiguen, qué no cambia y qué se hará con el tiempo ganado cuesta una reunión y evita un fracaso duradero.

Cuándo la integración de la IA no es la respuesta adecuada

En resumen: Un volumen demasiado bajo, datos que no deben salir de su entorno, una exigencia de exactitud que el modelo no garantiza o un proceso que ganaría antes con simplificarse: en esos casos, la integración no se justifica.

El primer caso es el del volumen. Implantar, ajustar, documentar y formar representa un esfuerzo real, y ese esfuerzo solo se amortiza si recae sobre una tarea que vuelve a menudo. Una operación ocasional, por penosa que sea, rara vez gana con automatizarse: el tiempo dedicado a describir correctamente lo que se espera supera al que se habría empleado en hacerla. Existe sin embargo una excepción, la de las tareas poco frecuentes pero arriesgadas, en las que el interés no es el tiempo ganado sino la regularidad del resultado.

El segundo caso es el de los datos que no deben salir de su entorno, por razones contractuales, normativas o de simple prudencia. Existen soluciones —modelos alojados en su propia infraestructura, anonimización previa, tratamiento limitado a extractos que no identifican a nadie—, pero tienen un coste de implantación y a veces una calidad menor. Si lo esencial del valor pasa por transmitir precisamente aquello que no puede salir, conviene decirlo pronto en lugar de descubrir el obstáculo con el proyecto ya en marcha.

El tercer caso es el de la exactitud. Un modelo produce un texto verosímil, no un valor garantizado. Para un cálculo, una regla normativa, un umbral contable o cualquier decisión que deba ser reproducible y justificable, una regla explícita o una fórmula sigue siendo superior: da siempre el mismo resultado y se verifica línea a línea. El modelo conserva un lugar útil antes o después —extraer los datos de un documento, explicar un resultado, redactar una síntesis—, pero no debería ser lo que decide.

El cuarto caso es el del proceso que conviene simplificar antes que automatizar. La pregunta menos costosa sigue siendo la más incómoda: ¿esta tarea debe existir? Muchos trabajos repetitivos son consecuencia de un dato introducido dos veces, de un formulario mal concebido o de un informe que ya nadie lee. Suprimir la causa cuesta menos que enseñar a una máquina a gestionar sus efectos, y el resultado es duradero.

Existe por último un caso menos nítido, el de la organización que aún no tiene una descripción escrita de sus propios procesos. La integración es entonces posible, pero empezará por ese trabajo de puesta en orden, y más vale anunciarlo que descubrirlo. Decir que una necesidad no corresponde a la IA no es una evasiva: es lo que hace creíble el momento en que se afirma que otra necesidad sí lo requiere.