Un cliente te escribe pidiendo "algo con inteligencia artificial" y no te dice qué problema quiere resolver. Antes de presupuestar, conviene poner orden en los términos, porque bajo la misma etiqueta conviven técnicas muy distintas y cada una sirve para otra cosa.
Tres capas que se mezclan
Inteligencia artificial es el paraguas más amplio: cualquier técnica que hace que un programa resuelva tareas que normalmente asociamos con una persona, como reconocer una cara, traducir o planificar una ruta. Incluye desde reglas escritas a mano hasta sistemas que aprenden solos.
Aprendizaje automático (machine learning) es una parte de ese paraguas. En lugar de programar las reglas, le mostrás ejemplos a un algoritmo y él ajusta sus parámetros para encontrar patrones. Un filtro de spam entrenado con miles de correos ya clasificados es un caso típico: nadie escribió la regla "si dice 'ganaste un premio', descartar", el modelo la dedujo de los datos.
Modelos generativos son modelos de aprendizaje automático que producen contenido nuevo: texto, imágenes, audio, código. Los modelos de lenguaje que se usan en chats y asistentes pertenecen a este grupo. Generan texto armando una respuesta pieza por pieza, y de ahí vienen tanto su utilidad como sus problemas.
Para el día a día, la diferencia práctica es esta: un clasificador clásico te devuelve una etiqueta de un conjunto cerrado; un modelo generativo te devuelve algo abierto, que puede estar bien, mal o a medias.
Dónde rinde bien
Los modelos actuales se llevan bien con tareas donde el resultado se puede revisar rápido y donde un error ocasional no es grave:
- Clasificar: ordenar tickets de soporte por tema, detectar el tono de un comentario, separar consultas comerciales de reclamos.
- Resumir: condensar un hilo largo de correos o una reunión transcripta.
- Extraer: sacar fecha, monto y razón social de un texto desordenado y devolverlos en un formato fijo.
- Generar borradores: un primer texto, un esqueleto de función, una respuesta tipo para que una persona la edite.
Lo que tienen en común estos casos es que hay alguien (o algo) que mira el resultado antes de que tenga consecuencias. El modelo acelera el primer 80 por ciento del trabajo y deja el resto a una persona. Eso no es una cifra medida, es una forma de decir que la entrega final sigue siendo humana.
Dónde no conviene apoyarse
Tampoco hay que pedirle al modelo lo que una base de datos o una función hacen mejor. Calcular un impuesto, buscar el saldo de una cuenta o aplicar una regla de negocio exacta es trabajo para código determinista: siempre da lo mismo con la misma entrada y podés probarlo. Un modelo puede sumar mal, o sumar bien hoy y mal mañana.
Tampoco es buena idea delegarle decisiones que tengan consecuencias legales, económicas o de seguridad sin una revisión humana. Y si necesitás que cada respuesta sea trazable hasta una fuente, hay que diseñar eso aparte, porque el modelo por sí mismo no sabe de dónde sacó lo que dice.
Por qué se equivoca con tanta seguridad
Este es el punto que más sorprende a quien recién empieza. Un modelo de lenguaje no consulta una enciclopedia: produce la continuación más plausible de un texto, según los patrones que aprendió. Plausible no quiere decir verdadero. Si le preguntás por una función que no existe en una librería, puede inventar una firma verosímil, con parámetros bien nombrados y un ejemplo de uso incluido.
Como la fluidez es la misma cuando acierta y cuando falla, el tono no te avisa. No hay un "creo que" automático. Por eso se habla de alucinaciones: respuestas bien redactadas que no corresponden a nada real.
De ahí salen algunos hábitos sencillos:
- Verificá lo que el modelo afirme y que vos no puedas confirmar de memoria, sobre todo nombres, números y citas.
- Diseñá el flujo para que haya una comprobación posterior: un test, una validación de formato, una persona que lea.
- Pedile salidas acotadas (una categoría de una lista, un JSON con campos definidos) en lugar de texto libre cuando eso alcance.
Qué te queda a vos
Elegir el problema, definir qué significa "correcto", armar los datos de prueba y decidir qué pasa cuando el modelo falla. Esas decisiones no se automatizan con el mismo modelo. Quien programa sigue siendo quien responde por el resultado, y entender estas tres capas es lo que permite decirle a un cliente, con argumentos, qué parte de su idea es razonable hoy y qué parte todavía necesita una persona al volante.