El ecosistema de herramientas de IA para empresas crece más rápido de lo que cualquier equipo técnico puede evaluar. Cada semana aparece un nuevo modelo, un nuevo framework o un nuevo proveedor que promete ser el definitivo. Para un CTO o un tech lead que necesita tomar decisiones de arquitectura que van a afectar el negocio durante años, ese ruido es el problema principal.
Este texto no es una lista de todas las herramientas de IA disponibles en 2024. Es la arquitectura que iAmanos usa en producción para las 29 aplicaciones que mantiene activas, con las razones reales detrás de cada decisión. No tenemos relación de afiliación con ninguno de los proveedores que mencionamos.
Los tres niveles del stack de IA empresarial
El stack de IA empresarial opera en tres niveles que deben diseñarse de forma coherente:
¿Tu empresa quiere implementar IA?
iAmanos ha construido 29+ apps de IA en producción en México. Cotiza tu proyecto en minutos.
- Nivel 1 — Modelos de lenguaje (LLM): el cerebro del sistema. Decide qué, por qué, en qué secuencia.
- Nivel 2 — Infraestructura de aplicación: el sistema que conecta el LLM con los datos y los usuarios de la empresa.
- Nivel 3 — Infraestructura de despliegue: dónde corre todo y cómo se mantiene.
Un error frecuente es optimizar el nivel 1 (elegir el modelo más potente disponible) sin tener claro cómo se va a integrar en los niveles 2 y 3. El resultado es un demo que impresiona y un sistema productivo que no funciona.
Nivel 1: Modelos de lenguaje — las opciones reales

Claude de Anthropic (nuestra elección principal)
Para la mayoría de las aplicaciones empresariales que construimos, usamos Claude. Las razones son técnicas, no de preferencia:
- Ventana de contexto grande (200,000 tokens): permite procesar documentos completos, bases de conocimiento extensas y conversaciones largas sin perder contexto. Para sistemas como la Terminal IA, que necesita mantener contexto de 60 mensajes de historial y cargar bases de conocimiento de 9,700 tokens, esto es esencial.
- Calidad de razonamiento en tareas complejas: para agentes que necesitan planificar secuencias de pasos y evaluar resultados intermedios, Claude Sonnet produce razonamiento más confiable y menos alucinaciones factuales que las alternativas en tareas de lógica de negocio.
- Seguridad por diseño: en aplicaciones que manejan datos sensibles de empresas o pacientes, el entrenamiento de seguridad de Anthropic reduce el riesgo de outputs problemáticos.
Modelo que usamos en producción actualmente: claude-sonnet-4-6. Disponible en Terminal IA, Capico CRM, PrintDesk (12 módulos con IA), BPack Chat y múltiples aplicaciones del ecosistema.
Gemini de Google (casos específicos)
Usamos gemini-2.5-flash en casos donde necesitamos búsqueda en internet en tiempo real (Grounded Search) o donde el costo por token es el factor determinante. Fay Route Optimizer usa Gemini para la investigación de direcciones que requieren información actualizada de Google Maps y Places.
Nota técnica importante: gemini-2.0-flash está deprecado y gemini-1.5-flash no está disponible en el SDK v1beta. El único modelo funcional en producción actualmente es gemini-2.5-flash.
Google Imagen 4 (generación de imágenes)
Para generación de imágenes profesionales usamos imagen-4.0-ultra-generate-001 con fallback a imagen-4.0-generate-001. Fenga, nuestra fábrica de diseños IA, y PrintDesk Design Studio usan este modelo para generar materiales visuales profesionales.
Límites reales: cuota aproximada de 70 imágenes por día con algunas restricciones de contenido. Para proyectos con alto volumen de generación, hay que planificar el uso dentro de estos límites.
Cuándo no usar LLMs
Los LLMs no son la solución para todo. No los usamos para:
- Búsquedas en bases de datos estructuradas que se pueden resolver con SQL bien escrito
- Cálculos matemáticos críticos (facturación, inventario) donde la precisión exacta es necesaria
- Procesamiento de imágenes que no requiere comprensión semántica
- Lógica de negocio determinista que no tiene variabilidad
Nivel 2: Stack de aplicación
Next.js como framework central
Usamos Next.js 16 con TypeScript en todas las aplicaciones. La razón principal es la cohesión entre frontend y backend en un solo codebase: las API routes de Next.js permiten construir el backend de la aplicación sin necesidad de un servicio separado, lo que reduce la complejidad operativa significativamente.
Las características que más usamos en contexto de IA:
- Streaming responses: para respuestas de IA en tiempo real sin bloquear la UI. Esencial en cualquier interfaz de chat.
- Server Actions: para operaciones que necesitan estar en el servidor por razones de seguridad (claves API, acceso a base de datos).
- App Router: layouts anidados que permiten construir experiencias de usuario complejas sin duplicar código.
Nota sobre Next.js 16: hay breaking changes importantes respecto a versiones anteriores. searchParams y params son ahora Promise<> y requieren await. cookies() y headers() son async. El archivo de middleware se llama proxy.ts, no middleware.ts. Documentar estos cambios previene horas de debugging.
Prisma 7 + PostgreSQL
Para la base de datos, PostgreSQL 16 con Prisma 7 como ORM. La ventaja de este stack es el tipado estricto: el schema de Prisma genera tipos TypeScript automáticamente, lo que elimina una categoría completa de errores en tiempo de ejecución.
Consideraciones críticas para Prisma 7:
- El datasource no lleva
urldirectamente en el schema; se configura enprisma.config.ts - En Docker, las tablas deben crearse via
psqldirecto o el CLI falla en build time - Los campos
BIGSERIALproducenBigInten JavaScript que no puede serializarse a JSON. Solución: castearid::textyqty::floaten el SQL
NextAuth v5 para autenticación
La autenticación con roles es un componente crítico de cualquier aplicación empresarial. NextAuth v5 con JWT strategy y credenciales locales cubre el 90% de los casos sin necesidad de integrar servicios externos de identidad.
Para aplicaciones con múltiples roles (como Capico con 10 roles o WouWou con ADMIN/MVZ/RECEPCION/TUTOR), el JWT incluye el rol del usuario y el ID del tenant, permitiendo filtrar todas las queries por estos valores sin pasos adicionales.
Arquitectura de multi-tenancy
Para SaaS con múltiples clientes (WouWou, GlamBook, FisioCore), usamos multi-tenancy por columna: cada registro tiene un campo clinicId o businessId que se filtra en todas las queries. Es más simple de implementar y mantener que esquemas separados por tenant, y suficiente para el volumen de datos que manejan estas aplicaciones.
Tailwind CSS + Framer Motion para UI
Tailwind CSS v4 para estilos y Framer Motion para animaciones. Esta combinación permite construir interfaces que se ven profesionales sin necesidad de un equipo de diseño dedicado, siempre que se tenga un sistema de diseño consistente definido desde el principio.
Nivel 3: Infraestructura de despliegue

Docker multi-stage + Traefik
Todas las aplicaciones se despliegan en contenedores Docker con builds multi-stage (separar dependencias de desarrollo de las de producción reduce el tamaño de la imagen final significativamente). Traefik maneja el SSL automático con Let’s Encrypt y el enrutamiento entre contenedores.
La sintaxis de Traefik para múltiples dominios es crítica: Host('a') || Host('b') nunca con coma. El certresolver se llama mytlschallenge. Errores en estas configuraciones producen problemas de SSL que pueden tardar horas en diagnosticar.
Un .dockerignore correcto es obligatorio. Sin él, el build de TypeScript puede fallar por directorios que solo existen en el VPS pero no en el código fuente.
VPS Hostinger
Usamos VPS Hostinger con IP 168.231.64.157 como infraestructura principal. Para la mayoría de las aplicaciones empresariales de las que hablamos en este texto, un VPS de este tipo es suficiente: ofrece control total sobre la configuración, costos predecibles y sin sorpresas de pricing variable como los servicios cloud por uso.
El modelo de deploy que usamos: rsync del código local al VPS (siempre con --exclude='.env' para no sobrescribir variables de entorno de producción), docker build en el VPS, y docker compose up -d para levantar el contenedor actualizado.
Gestión de variables de entorno
Las claves API nunca van en el código. Siempre en .env en el VPS, nunca sincronizadas al repositorio, nunca hardcodeadas. Para cada proyecto hay un .env de referencia (sin valores reales) que documenta qué variables se necesitan.
Herramientas de IA para el proceso de desarrollo
Además del stack de producción, usamos IA en el propio proceso de construcción:
- Claude Code: para escribir, revisar y refactorizar código. La base de nuestra metodología de Vibe Coding.
- Terminal IA (propia): para coordinar deploys, revisar logs y gestionar la infraestructura sin salir del contexto de desarrollo.
Lo que no usamos y por qué

Esta sección es tan importante como lo que sí usamos:
- LangChain: la abstracción añade complejidad sin suficiente beneficio para los casos que resolvemos. Integramos directamente con las APIs de Anthropic y Google.
- Vercel: ofrece menos control y costos variables que pueden escalar sin previo aviso. El VPS propio con Traefik da los mismos resultados con más control.
- MongoDB: para aplicaciones con relaciones de datos complejas, PostgreSQL con Prisma produce consultas más eficientes y tipado más seguro.
- Microservicios desde el principio: para aplicaciones de tamaño mediano, el monolito modular en Next.js es más rápido de construir y más fácil de mantener. La separación en microservicios tiene sentido cuando el volumen lo justifica, no como decisión inicial.
Decisiones de arquitectura que más afectan el costo a largo plazo
- El schema de base de datos inicial. Cambiarlo después de que hay datos en producción es costoso. Invertir tiempo en diseñarlo bien al principio es la decisión técnica de mayor impacto.
- La estrategia de autenticación y autorización. Añadir roles después de construir el sistema es refactorizar el 30% del código. Definir los roles desde el principio y construir con ellos en mente desde el día uno.
- La separación entre lógica de negocio y presentación. Los componentes de UI que contienen lógica de negocio son imposibles de testear y difíciles de mantener. La separación correcta desde el inicio reduce el costo de cada cambio posterior.
Cómo evaluar un stack para tu empresa

Antes de adoptar cualquier tecnología nueva, tres preguntas que deben tener respuesta:
- ¿Quién lo mantiene cuando el proveedor lo cambia o descontinúa? Los modelos de IA se actualizan, deprecan y cambian de API. Tu arquitectura debe ser resiliente a esos cambios.
- ¿Dónde viven tus datos? Para datos de clientes, datos médicos o información financiera, la jurisdicción donde se almacenan los datos importa para cumplimiento regulatorio.
- ¿Puedes operar si la API del proveedor cae? Un sistema que depende de una sola API externa sin fallback ni modo offline tiene un punto único de falla.
El siguiente paso
Si estás evaluando la arquitectura correcta para una aplicación de IA en tu empresa, la conversación más útil es técnica y específica a tu caso. Los stacks correctos varían por volumen de datos, número de usuarios, requisitos de cumplimiento y capacidad técnica interna del equipo que va a mantener el sistema.
Agenda una sesión técnica en coti.iamanos.com. Sin compromiso, sin presentación de ventas.