Hoy casi cualquier producto quiere "tener IA". A veces tiene sentido. Otras veces es un adorno: un botón que dice "con inteligencia artificial" sobre una función que se resolvía mejor con una regla simple.
Nuestro enfoque es el de la IA aplicada: usarla cuando resuelve un problema concreto, con límites claros, y no como decoración. Este artículo resume cómo lo pensamos.
Dónde suele aportar valor
La IA generativa y los modelos de lenguaje son buenos para tareas donde la entrada es desordenada y las reglas exactas son difíciles de escribir. Algunos casos típicos:
- Asistentes internos. Responder consultas sobre documentación propia, ayudar a redactar o a buscar información dentro de la empresa.
- Clasificación. Ordenar mensajes, tickets o pedidos en categorías cuando el texto viene en lenguaje natural.
- Extracción de documentos. Sacar campos estructurados (fechas, importes, nombres) de textos o PDFs con formatos variables.
- Sistemas internos. Resumir, sugerir borradores o priorizar, siempre como ayuda para una persona.
En todos estos casos hay algo en común: la salida de la IA es una propuesta que se puede verificar, no una verdad que se ejecuta a ciegas.
Dónde no aporta (o no alcanza)
También hay problemas donde la IA no es la mejor respuesta:
- Cuando existe una regla exacta. Si el descuento es 10 por ciento a partir de cierto monto, eso se programa; no se le pregunta a un modelo.
- Cuando el error es muy costoso y no hay forma de revisar. Una respuesta plausible pero incorrecta puede ser peor que no tener respuesta.
- Cuando no hay datos ni contexto suficientes. Sin información de la operación real, el modelo improvisa.
- Cuando el problema de fondo es de proceso, no de procesamiento. Automatizar un flujo mal pensado solo lo hace fallar más rápido.
Cuatro guardas que consideramos básicas
1. Humano en el circuito
Cuando la decisión importa, una persona revisa o aprueba. La IA acelera el trabajo; no lo reemplaza sin supervisión. Definir qué decide la máquina y qué decide una persona es parte del diseño, no un detalle.
2. Validar lo que devuelve el modelo
Una salida de IA es texto. Antes de usarla en un sistema hay que comprobar que tiene la forma esperada y valores razonables. Si no los tiene, se descarta o se manda a revisión.
3. Plan B sin IA
Los servicios de IA pueden fallar, tardar o cambiar. El sistema tiene que seguir funcionando, aunque sea de manera más manual, cuando eso pasa. Un fallback bien pensado es lo que separa una función útil de un punto único de falla.
4. Registro y trazabilidad
Guardar qué entró, qué salió y qué se decidió permite corregir errores, mejorar con evidencia y explicar el comportamiento del sistema.
Un ejemplo ilustrativo
El siguiente fragmento es solo una ilustración, no un sistema real. Clasifica un mensaje entrante y valida la respuesta del modelo con zod; si algo no cuadra, no confía en ella y deriva a una persona.
import { z } from "zod";
const ClassificationSchema = z.object({
category: z.enum(["consulta", "reclamo", "pedido", "otro"]),
confidence: z.number().min(0).max(1),
});
type Classification = z.infer<typeof ClassificationSchema>;
// Anything the model returns is untrusted until it passes validation.
export async function classifyMessage(
text: string,
callModel: (text: string) => Promise<unknown>,
): Promise<Classification & { source: "ai" | "fallback" }> {
try {
const parsed = ClassificationSchema.parse(await callModel(text));
if (parsed.confidence >= 0.8) return { ...parsed, source: "ai" };
} catch {
// Network error, timeout or invalid shape: fall through to the fallback.
}
// Fallback: no AI result we can trust, so a person reviews it.
return { category: "otro", confidence: 0, source: "fallback" };
}Fijate qué hace y qué no hace. Valida la forma de la respuesta, exige un umbral mínimo de confianza (el valor 0.8 es solo un ejemplo y habría que calibrarlo con datos reales), y ante cualquier duda devuelve un resultado marcado como fallback para que una persona lo revise. Cada clasificación indica si vino de la IA o del plan B, lo que facilita registrar y auditar.
El costo también es un requisito
Usar IA tiene costos que se miran desde el diseño: el precio por uso, la latencia, el esfuerzo de mantener y evaluar el sistema, y la dependencia de un proveedor. No damos cifras genéricas porque dependen del caso, del volumen y del modelo elegido; lo importante es estimarlos con el caso real y no descubrirlos después.
Una práctica útil es empezar con un alcance chico, medir con ejemplos reales y recién después decidir si ampliar. Esto es coherente con cómo clasificamos la madurez de las cosas, como contamos en Prototipo, MVP, piloto y producto.
Preguntas para hacerte antes de sumar IA
- ¿Qué problema concreto resuelve? Si no podés decirlo en una frase, todavía no hay un caso.
- ¿Hay una solución más simple? Una regla, un filtro o una búsqueda quizás alcancen.
- ¿Cómo sabés si la respuesta es correcta? Definí cómo vas a evaluar la calidad antes de construir.
- ¿Qué pasa cuando se equivoca? Mirá el peor caso razonable y decidí si es tolerable.
- ¿Quién revisa y cuándo? Dejá definido el punto donde interviene una persona.
- ¿Qué pasa si el servicio no responde? Tené un plan B funcionando.
- ¿Qué datos se envían y a quién? Revisá qué información sale de tu sistema y bajo qué condiciones.
- ¿Cuánto cuesta sostenerlo? Incluí uso, mantenimiento y evaluación.
Resumen
- La IA aporta cuando la entrada es desordenada y la salida se puede verificar.
- No la uses donde una regla exacta alcanza o donde el error no se puede revisar.
- Guardas básicas: humano en el circuito, validar la salida, plan B sin IA y trazabilidad.
- Estimá costo y calidad con casos reales antes de ampliar el alcance.
Si estás evaluando dónde podría ayudar la IA en tu operación, mirá cómo trabajamos o contanos el caso. Si la conclusión es que no la necesitás, te lo vamos a decir.