Cuándo añadir funciones de IA a su aplicación — y cuándo no

Ahora mismo pesa sobre cada responsable de producto una presión silenciosa para acoplar IA a lo que sea que esté construyendo. Los inversores preguntan por ella. Los competidores la ponen en sus titulares. Un miembro del consejo reenvía un artículo. Y así, una aplicación perfectamente buena acaba con un iconito brillante y una ventana de chat que nadie pidió y que casi nadie usa. La función se lanza, sale la nota de prensa y, seis meses después, las gráficas de uso están planas. La pregunta nunca fue si <em>podía</em> añadir IA. Era si debía hacerlo.

Me dedico a desarrollar software y funciones de IA para pequeñas y medianas empresas, lo que significa que tengo un incentivo económico para decirle que añada IA a todo. Voy a hacer lo contrario. Lo más valioso que puedo ofrecerle es una forma de saber —antes de comprometer presupuesto— si una función de IA va a aguantar su peso en silencio o a pudrirse en silencio. Porque aquí el fracaso no es dramático. Las funciones de IA rara vez explotan. Simplemente se quedan ahí, sin uso ni cariño, costándole dinero en cada llamada a la API y un poco de credibilidad cada vez que un usuario la toquetea y se marcha.

Esta guía es el marco que uso de verdad en esas conversaciones. Sin palabras de moda, sin nombres de modelos a la última, sin fingir que un modelo de lenguaje es la respuesta a una pregunta que aún no se ha hecho. Solo una forma práctica de decidir qué pertenece a su app, qué pertenece al código sencillo y qué pertenece a la papelera.

Por qué fracasan en silencio la mayoría de las funciones de IA acopladas

Cuando una función de IA fracasa en un producto pequeño, casi nunca es porque el modelo no fuera lo bastante listo. Fracasa porque la función se eligió por las razones equivocadas. Alguien quería tener IA, en lugar de querer resolver algo concreto y doloroso que casualmente necesitaba IA. La tecnología era el objetivo y el problema del usuario, una ocurrencia tardía. Los usuarios lo huelen al instante.

El segundo fracaso habitual es más sutil: la función resuelve un problema real, pero un problema que el código sencillo habría resuelto de forma más barata y fiable. Un botón con la etiqueta «con IA» que solo ordena una lista por fecha es un lastre, no una función. Ha cogido algo determinista, lo ha hecho más lento, más caro y a veces erróneo, y luego ha anunciado el empeoramiento. Los usuarios también se dan cuenta de eso.

El tercer fracaso es la confianza. Las funciones de IA son probabilísticas: aciertan la mayoría de las veces y se equivocan con aplomo algunas. Si coloca una en un flujo donde una respuesta errónea sale cara y el usuario no tiene forma de detectarla, no ha añadido una función, ha añadido una mina. La buena noticia es que los tres modos de fracaso son predecibles, lo que significa que son evitables. Solo tiene que hacer las preguntas correctas antes de empezar, no después de lanzar.

La prueba honesta: ¿es esto de verdad un problema de IA?

Este es el filtro más útil que conozco. Para cualquier función que le tiente hacer «inteligente», pregúntese: ¿esta tarea sigue reglas fijas o requiere entender una entrada humana y desordenada? Si la tarea sigue reglas —ordena por esto, calcula aquello, envía un recordatorio dos horas antes—, quiere código sencillo. Es más barato, más rápido, totalmente predecible y nunca alucina. Llamarlo IA es solo marketing caro.

La IA se gana su sitio donde la entrada es de verdad desordenada y de forma humana: texto libre que las reglas no pueden anticipar, imágenes, voz, documentos en cien formatos distintos, lenguaje que hay que entender en lugar de cotejar. Son las cosas que antes eran imposibles de automatizar. Si su función vive ahí, la IA no es un truco, es la única forma práctica de construirla. La destreza está en distinguir ambas categorías con honestidad, sobre todo cuando hay presión por llamarlo todo IA.

Dónde encaja de verdad la IA en una app

Seamos concretos. Tras años construyendo estas cosas, una breve lista de patrones no deja de demostrar su valor, no porque estén de moda, sino porque la tarea de fondo trata de verdad de entender una entrada no estructurada. Son las funciones a las que los usuarios vuelven de verdad.

• Convertir texto libre en datos estructurados: leer un correo divagante de un cliente y extraer el pedido, la dirección y el plazo.
• Redactar una primera versión —una respuesta, un resumen, una descripción— que luego edita una persona, en vez de que la IA la envíe sin supervisión.
• Una búsqueda que entienda el significado, no solo las palabras clave, para que los usuarios encuentren el documento correcto aunque lo formulen de forma distinta a como usted lo archivó.
• Clasificar o enrutar una avalancha de elementos entrantes —tickets de soporte, correos, subidas— para que cada cosa llegue a su sitio.
• Extraer información de documentos e imágenes: facturas, recibos, formularios, fotos tomadas sobre el terreno.
• Ayuda conversacional sobre sus propios datos, donde un usuario hace una pregunta sencilla y obtiene una respuesta anclada en su contenido.

Fíjese en el patrón. En todos estos casos, la entrada es impredecible y humana, y un pequeño margen de error es tolerable porque hay una persona en el proceso o el coste de un fallo es bajo. Esa combinación —entrada desordenada, riesgo indulgente— es el hogar natural de una función de IA. Cuando encuentre una tarea que encaje en ambas mitades, probablemente haya encontrado una función que vale la pena construir.

Dónde es mejor no tocar la IA

Igual de importante es saber dónde no recurrir a la IA, porque la ubicación equivocada no solo malgasta dinero: erosiona activamente la confianza que su producto se ha ganado. Algunas tareas parecen tentadoras y resultan ser trampas.

Hay también un coste más callado. Cada función de IA es ahora algo que debe vigilar, evaluar y pagar en cada llamada. Tres funciones de IA en las que sus usuarios confían valen más que diez que de vez en cuando le avergüenzan. Un modelo que se equivoca delante de un cliente en el momento equivocado puede deshacer un año de credibilidad construida con cuidado. La contención aquí no es timidez: es sentido de producto.

Un mapa rápido: constrúyalo, déjelo o hágalo más tarde

Para hacerlo menos abstracto, así suelen quedar un puñado de ideas habituales del tipo «pongamos IA» cuando se pasan por la prueba anterior. Tómelo como un valor por defecto sensato con el que discutir, no como un dogma.

La forma de la tabla es la lección. Los síes se agrupan donde la entrada es desordenada y el riesgo es indulgente. Los noes se agrupan donde la tarea es de verdad basada en reglas, o donde una respuesta errónea duele y nadie comprueba. Si puede situar su idea en esa cuadrícula con honestidad, ya ha tomado la mayor parte de la decisión.

Momento: incluso una buena función de IA puede añadirse demasiado pronto

A veces la función encaja de verdad y la respuesta sigue siendo todavía no. Las funciones de IA tienen un requisito previo sigiloso que los fundadores subestiman: solo son tan buenas como los datos y el flujo de trabajo sobre los que se asientan. Una búsqueda semántica sobre sus documentos es maravillosa... una vez que sus documentos están realmente organizados. Un asistente que responde preguntas sobre su producto es brillante... una vez que el contenido de su producto no es un lío contradictorio. La IA amplifica todo aquello sobre lo que se construye, el caos incluido.

Así que, antes de añadir la capa ingeniosa, asegúrese de que la capa aburrida de debajo es sólida. Si su app principal aún está afianzándose, verter tiempo de ingeniería en una función de IA suele ser pedir prestado de la cuenta equivocada. La verdad poco glamurosa es que el mejor momento para añadir IA suele ser después de haber afianzado los fundamentos, cuando tiene usuarios reales, datos reales y un dolor claro y repetitivo que la IA está en posición única para eliminar.

Cómo añadir una función de IA sin arrepentirse

Supongamos que ha encontrado una función que pasa la prueba: entrada desordenada, riesgo indulgente, un cimiento sólido debajo, un dolor real que eliminar. Bien. Ahora viene la parte en la que los equipos construyen algo duradero o algo que arrancarán en silencio el año que viene. Trátelo como un experimento cuidadoso, no como un lanzamiento.

1. 1
   Escriba el trabajo en una sola frase

   «El asistente lee un correo entrante y rellena el formulario de pedido, que una persona confirma.» Si no puede escribir esa frase, la función no está lista: sigue enamorado de la tecnología, no de la tarea.
2. 2
   Mantenga al principio a una persona en el proceso

   Deje que la IA redacte, sugiera o rellene de antemano, y deje que una persona apruebe. Aprenderá dónde es fiable y dónde no antes de confiarle nunca actuar sola, si es que lo hace alguna vez.
3. 3
   Decida qué pasa cuando se equivoca

   Las funciones probabilísticas necesitan un fallo elegante. ¿Cómo se da cuenta el usuario? ¿Cómo lo corrige? Una función de IA sin un «deshacer» o un «esto no está bien» visible es una función en la que no puede confiar en producción.
4. 4
   Mida el uso, no la novedad

   Siga si la gente la usa de verdad después de la primera semana y si ahorra el tiempo que prometió. Una función que se dispara en el lanzamiento y se aplana después le está diciendo algo. Escuche.
5. 5
   Esté dispuesto a quitarla

   Si los números dicen que no se gana su sitio, córtela. Un producto más pequeño que hace unas pocas cosas de forma fiable supera a uno hinchado y tachonado de funciones de IA que nadie toca.

El hilo que recorre los cinco pasos es la humildad ante el error. El código sencillo o funciona o tiene un fallo que usted corrige. La IA acierta la mayoría de las veces y se equivoca algunas, para siempre: esa es su naturaleza, no un defecto que pueda parchear. Diseñe la función en torno a esa realidad y se convierte en un activo. Finja que la IA siempre acierta y habrá construido la mina de la que hablábamos antes.

El panorama general: la IA es una herramienta, no una estrategia

Si se aleja lo suficiente, toda la cuestión se vuelve más simple. La IA es una herramienta, igual que lo es una base de datos o una barra de búsqueda. No construye un producto en torno a tener una base de datos; usa una base de datos donde mejora el producto. La misma contención le sirve bien aquí. Las empresas que obtienen valor real de la IA no son las que añadieron más, son las que la añadieron exactamente en los pocos sitios donde elimina una fricción genuina, y se contuvieron en todos los demás.

Esa contención es también, por cierto, lo que hace que la IA que sí añade resulte impresionante. Cuando cada pantalla tiene un asistente a medio hacer, ninguno parece especial. Cuando una función lee en silencio el correo de un cliente y le ahorra a su equipo diez minutos cada vez, la gente lo recuerda. Menos, más afilada, de verdad útil: esa es la versión de la IA que vale la pena construir, y la versión por la que sus usuarios le darán de verdad las gracias.

Preguntas frecuentes