Tipos de IA — la clasificación que importa

Tipos de IA — la clasificación que importa

Por qué la taxonomía operacional importa más que la académica

La clasificación de inteligencia artificial que enseñan en departamentos de investigación es rigurosa pero poco útil para quien tiene que decidir qué herramienta usar el martes a la mañana. Para el profesional, hace falta una traducción.

La que sirve es tridimensional. Capacidad (estrecha o general). Tipo de salida (generativa o analítica). Arquitectura de despliegue (en la nube o local). Cada punto en ese espacio define una herramienta distinta con un set propio de trade-offs.

Esto no es académico. Es la matriz que aplico cuando un cliente me pregunta "¿qué herramienta de IA conviene?". La respuesta empieza por mapear su problema en estos tres ejes.

Eje 1: estrecha vs general — qué significa hoy

Hoy estamos plenamente en IA estrecha. Sistemas especializados. Cada uno es excelente en una tarea porque fue entrenado así, con arquitectura y datos ajustados a ese objetivo específico.

"Estrecha" no significa "débil". Claude puede escribir un memorando mejor que la mayoría de los humanos. Pero no puede andar en bicicleta. No por falta de entrenamiento. Por falta de cuerpo, de experiencia sensoriomotora, de contexto físico. La limitación es arquitectónica, no temporal.

AGI, como se discute en el AI Index Report de Stanford, sería el punto en el que un sistema aprende conceptos transversales, se adapta a tareas nunca vistas y generaliza de forma cercana a un humano. No existe. Hay especulación sobre cuándo podría llegar. Algunos investigadores serios sugieren entre 2030 y 2040. Otros son mucho más conservadores. Hoy, en abril de 2026, no existe.

La distinción es útil porque te enseña a modelar las limitaciones reales. No es "Claude no puede hacer X porque todavía no es lo suficientemente buena". Es "Claude no hace X porque no fue entrenada para eso, y eso no se arregla con un release". La primera lectura te lleva a esperar. La segunda te lleva a buscar la herramienta correcta.

Eje 2: generativa vs analítica — estructuras distintas

La confusión acá es profunda porque ambas usan IA moderna, ambas procesan datos y ambas dan respuestas. Pero las estructuras subyacentes son radicalmente distintas.

Generativa predice secuencias. Un LLM predice el siguiente token basado en distribuciones de probabilidad aprendidas durante el entrenamiento. Es regresión sobre distribuciones. Excelente para síntesis, exploración, creatividad y prototipado. Mala para procesar grandes volúmenes con exactitud, para detección de anomalías estadísticas o para series temporales donde la precisión importa.

Analítica busca patrones estructurales en datos. Usa álgebra lineal, estadística clásica, algoritmos de clustering, modelos de regresión. Es determinista o pseudo-determinista con intervalos de confianza. Excelente para decisiones donde necesitás trazabilidad, para modelos de riesgo y para dashboards operacionales. Mala para generar variaciones creativas, para escribir prosa o para exploración abierta.

Hay overlap, claro. Un LLM puede hacer análisis vía prompt engineering y razonamiento emergente. Una base analítica puede generar reportes sintéticos. Pero el costo cognitivo y computacional es muy distinto. Es ineficiente usar la herramienta equivocada solo porque ambas "técnicamente pueden".

Caso concreto. Análisis de un dataset de 50.000 registros vía Claude (generativa, basada en prompts) versus una query SQL sobre una tabla indexada (analítica, estructura relacional). La segunda es más rápida, más barata y más confiable. La primera es más flexible y más exploratoria.

Yo aplico una heurística simple. Si el problema es "¿qué oportunidades hay acá?" (abierto), generativa. Si el problema es "¿cuántas unidades se vendieron por región el último trimestre?" (cerrado), analítica.

Eje 3: en la nube vs local — arquitectura, no nostalgia

El debate cloud vs local no es "qué es más rápido". Es "qué arquitectura resuelve tu restricción".

En la nube implica conectividad, infraestructura centralizada, capacidad de escala prácticamente ilimitada, acceso a contexto global (web, APIs externas), persistencia de conversación e integración con un ecosistema amplio de herramientas. El costo: precio por token, latencia de red y datos que transitan por servidores de un tercero.

En local implica cómputo en la máquina del usuario, sin dependencia de red, costo marginal cercano a cero después de la instalación, máxima privacidad (nada sale del equipo) y ninguna integración automática con servicios externos. La limitación: la GPU o CPU local es finita, no hay acceso a actualizaciones en tiempo real y no hay memoria multiconversación persistente fuera de lo que vos diseñes.

Para trabajo en tiempo real (escritura, análisis rápido, integración con herramientas cotidianas), la nube es prácticamente obligatoria. Para procesamiento de documentos confidenciales (legal, médico, datos regulados), el local tiene mucho sentido, asumiendo que la máquina local tenga buenas prácticas de seguridad. Para sistemas autónomos que corren continuamente, suele ser mejor un híbrido (cómputo local con checkpoints en la nube).

No hay un ganador absoluto. Hay un ganador para tu restricción.

La matriz completa y dónde mapear las herramientas conocidas

Si combinás los tres ejes, te queda este mapa práctico:

Estrecha + generativa + nube: Claude, GPT-4o, Gemini. Es el mainstream para 2026. Buena para alrededor del 95% del trabajo intelectual de oficina.

Estrecha + generativa + local: Llama 3 (Meta), Mixtral (Mistral), Phi (Microsoft). Menos potencia bruta. Más privacidad. Útil para tareas confidenciales o para integraciones donde el costo por token no cierra.

Estrecha + analítica + nube: Palantir Foundry, Databricks, BigQuery, Snowflake. Big data. Machine learning a escala empresarial.

Estrecha + analítica + local: pandas y DuckDB en tu laptop. Análisis rápido de datasets medianos sin pasar por la nube.

AGI no aparece en la matriz porque no existe. Si apareciera, la matriz cambiaría entera.

Lo que la mayoría no ve al evaluar herramientas

Cuando alguien evalúa una herramienta de IA, mira el benchmark. "¿Qué puntaje saca en MMLU?" Eso es señal débil.

Lo que importa es dónde cae la herramienta en este espacio tridimensional, y si ese punto resuelve tu problema. No el problema de un benchmark genérico.

Claude hoy es excelente en su punto del espacio. Estrecha, generativa, multimodal, en la nube. Si tu problema requiere AGI, esperá. Si requiere análisis estructurado puro, usá SQL o un BI. Si requiere local con privacidad estricta, hay opciones. Pero si tu problema es "necesito escribir 50 emails personalizados en dos horas, leyendo el historial de cada cliente", eso cae exactamente en el cuadrante donde Claude domina.

Trayectoria a corto y mediano plazo

A corto plazo, multiplicación de especializaciones. Modelos estrechos cada vez más afinados para verticales específicos (medicina, código, legal, soporte). No es señal mala. Es realismo. Modelos generales para todo terminan siendo mediocres en cada cosa específica.

A mediano plazo, sistemas híbridos. Generativa más analítica en el mismo producto. Claude ya empieza con esto. Puede escribir y analizar archivos en la misma conversación. La barrera entre los dos paradigmas se está disolviendo a nivel de producto, aunque no a nivel de arquitectura interna.

A largo plazo, la pregunta de AGI sigue abierta. Si llega, la taxonomía cambia. Por ahora, no afecta lo que hacés esta semana.

La tesis del blog

Llevo años trabajando con IA aplicada y llegué a una postura que sostengo. La gente que mejor decide qué herramienta usar no es la que más sabe de modelos ni la que más sigue las novedades. Es la que aprendió a hacerse las tres preguntas correctas antes de elegir.

Estrecha o general. Generativa o analítica. En la nube o local.

Quien hace eso con disciplina toma decisiones de arquitectura mucho más sólidas que quien se deja llevar por el último anuncio. Le ahorra tiempo, plata y frustración a su equipo.

La próxima vez que alguien te diga "deberíamos usar IA para esto", parte la conversación en esos tres ejes. Vas a ver que la mitad de las veces la herramienta correcta no es la que el otro tenía en mente. Y que la otra mitad de las veces, sí lo es, pero por razones que ahora podés explicar.

Eso es la diferencia entre usar IA y entender IA. Y se nota en los resultados.