Tu competidor lanzó una función de IA el trimestre pasado. La junta directiva preguntó por tu roadmap. Tu cofundador no deja de enviarte enlaces.
Así que vas a agregar funciones de IA. La pregunta es si serás el equipo que agregó una función, o el equipo que agregó un centro de costos con una envoltura con forma de función. La brecha entre esos dos resultados no es la calidad del modelo — son las decisiones que se toman en las primeras dos semanas: qué función, qué arquitectura, qué dicen los números de tokens y cómo le pones precio.
Este playbook recorre esas decisiones en orden: qué significa realmente «agregar IA», cómo elegir la primera función, cómo diseñar la arquitectura sin reconstruir tu SaaS, cómo hacer las unit economics para que la función genere dinero en lugar de quemarlo, y los errores que convierten las funciones de IA en pasivos. Todo lo técnico apunta a nuestras guías existentes — este artículo se mantiene en la capa de producto y estrategia.
Qué significa realmente «agregar IA» a tu SaaS
En resumen: hay tres tipos de funciones de IA y solo uno de ellos es una estrategia de producto.
- Funciones de asistencia — resumir, recomendar, traducir, autocompletar. Mejoran un flujo existente. Riesgo bajo, techo bajo.
- Funciones de automatización — triage de soporte, extracción de documentos, enriquecimiento de datos. Reemplazan trabajo manual. Riesgo medio, ROI real y medible.
- Funciones de nueva categoría — una capacidad que tu categoría no tenía, como analítica conversacional sobre los datos propios de tus clientes. Riesgo alto, potencialmente transformadoras, imposibles de comparar con la competencia porque nadie las tiene.
La confusión que mata presupuestos: tratar un wrapper como si fuera una estrategia. Un panel de chat atornillado a tu dashboard no es una función de IA — es un panel de chat. El mercado ya entrenó a tus usuarios para que lo reconozcan por lo que es. Las funciones de IA reales cambian un flujo de trabajo, no solo una pantalla.
Por qué importan las funciones de IA
En resumen: las funciones de IA son hoy una palanca de retención y de precios — y su ausencia es una señal competitiva.
Los datos de 2026 son consistentes en las encuestas de la industria: las funciones de IA se correlacionan con mayores tasas de activación y mejor retención en los productos SaaS, y las capacidades nativas de IA aparecen cada vez más en los niveles de precios como capa de diferenciación. No vamos a citar un estudio sin metodología — el patrón es visible en tu propio funnel: una función que responde una pregunta o elimina un paso convierte mejor que una que agrega fricción.
El costo de no hacer nada es más agudo que hace un año. Cuando todos los competidores tienen un nivel con IA, no tenerlo se lee como una señal — sobre tu roadmap, tus márgenes, tu equipo. Que sea justo o no es irrelevante; es lo que lee el mercado.
Cómo elegir tu primera función de IA
En resumen: elige la función con mayor frecuencia de uso × disposición a pagar, dividida entre el costo de implementación — y para la mayoría de los SaaS, ese es el soporte o el resumen.
Califica cada candidata en tres ejes:
| Eje | Qué medir | Peso |
|---|---|---|
| Frecuencia | ¿Con qué frecuencia la invocarían los usuarios al mes? | el más alto |
| Disposición a pagar | ¿Pagarían más, o bajaría el churn, por ella? | alto |
| Costo de implementación | Esfuerzo de integración + eval + guardrails | reductor |
Pasa tus ideas de funciones por esta tabla. El triage de soporte puntúa alto en los tres — se invoca a diario, es un ahorro de costos visible y tenemos una guía completa de arquitectura para chatbots de soporte de la que tomar prestado. El resumen de contenido puntúa alto en frecuencia y facilidad de implementación. La analítica conversacional puntúa alto en disposición a pagar, pero toma meses y un equipo de datos.
Una sesión de puntuación resuelta. Tres candidatas para un SaaS de gestión de proyectos: (a) resúmenes de reuniones generados automáticamente, (b) un asistente que responde preguntas sobre los proyectos del usuario, (c) predicción automática de riesgo en los cronogramas de proyectos. Frecuencia: los resúmenes se usan semanalmente, el asistente a diario, la predicción de riesgo mensualmente. Disposición a pagar: los resúmenes son requisito básico (baja), el asistente impulsa el upgrade de nivel (alta), la predicción de riesgo demuestra muy bien pero nadie está seguro de que pagarían por ella. Costo de implementación: los resúmenes son un pipeline acotado; el asistente necesita retrieval; la predicción de riesgo necesita datos históricos y una evaluación seria. La suma ponderada elige al asistente — y la sesión de puntuación convierte una discusión a gritos en una hoja de cálculo.
La recomendación por defecto para la primera función: soporte o resumen — alta frecuencia, resultado cuantificable e implementación acotada. Guarda el moonshot para la segunda función, después de haber construido la infraestructura de costos y evaluación.
Cómo diseñar la arquitectura de las funciones de IA
En resumen: cuatro decisiones de arquitectura determinan si tu función de IA escala o colapsa — y ninguna de ellas es «qué modelo».
- Siempre un backend proxy. Las API keys nunca tocan el frontend. Enruta cada llamada a través de tu backend, donde viven las keys, se aplican los límites y se acumulan los logs. Esto no es negociable y está cubierto en detalle en nuestra línea base de seguridad.
- Streaming, caché y batch — en ese orden de implementación. El streaming es un requisito de UX, no un extra agradable: los usuarios abandonan las UIs de chat sin streaming. El prompt caching reduce los costos de entrada en plantillas repetidas, y el procesamiento por batch recorta el costo de cualquier workload offline (embeddings, enriquecimiento, resúmenes nocturnos). Nuestra guía de optimización en producción tiene la mecánica.
- Enruta los modelos, no los ata. Un solo modelo para todo el producto es un punto único de falla y una situación de rehén de precios. Enruta por tarea: un modelo barato para clasificación, un modelo de frontera para la generación crítica para la UX. El routing personalizado es donde eso empieza — y es una configuración, no una arquitectura. La forma de referencia — así se ve una función de IA bien arquitecturada:
Frontend → Backend proxy (keys, limits, logs) → Router (task → model tier)
→ Fallback chain (provider B on failure)
→ Cache layer (repeated templates)
→ Usage/cost sink (per-feature attribution)Cuatro capas, cada una reemplazable, ninguna acoplada a un proveedor. Si tu función no se puede dibujar así, la arquitectura no está terminada — y el retrabajo costará más que dibujarla ahora.
- Eval antes del lanzamiento. Si no puedes medir si la función mejoró después del último cambio de prompt, estás lanzando esperanza. Un set de eval base con un umbral de aprobar/fallar es la diferencia entre una función de IA y un experimento — la disciplina de eval estilo CI que construimos en nuestro pipeline de pruebas es el patrón a copiar.
Cómo fijar el precio de las funciones de IA: unit economics de tokens
En resumen: una función de IA es un producto con un COGS — ponle precio como tal y mantén el margen bruto por encima del 70%.
Esta es la fórmula de unit economics que decide todo:
Cost per user per month =
(calls per user per month)
× (tokens per call, input + output)
× (price per token, blended)Ejemplo resuelto con rangos de mediados de 2026 (verifícalos contra los precios de OpenAI y los precios de Anthropic actuales): una función de resumen, 30 llamadas/usuario/mes, 4K de entrada + 1K de salida por llamada, precios de clase de frontera a aproximadamente $3/M de entrada y $15/M de salida promediados en la mezcla de llamadas — eso son alrededor de 150K tokens/usuario/mes a aproximadamente $0.81/usuario/mes de costo bruto de modelo. Con prompt caching (plantillas de documentos repetidas) y routing (modelo barato para documentos cortos), la misma función queda en $0.03-0.06/usuario/mes. Diez mil usuarios: unos $8,100/mes a precio de lista, o $300-600/mes con caching y routing — lo bastante poco para absorberlo, lo bastante grande como para que se note si lo ignoras.
Tres patrones de precios que funcionan:
| Patrón | Cómo funciona | Para quién |
|---|---|---|
| Inclusión en el nivel | Funciones de IA en el nivel medio/alto | B2B, uso acotado |
| Paquetes de uso | Comprar créditos/tokens por adelantado | Self-serve, alta varianza |
| Híbrido | Nivel base + tope de uso con excedente flexible | La mayoría de los equipos |
La regla de margen: mantén el margen bruto de las funciones de IA por encima del 70%. Si el costo del modelo se come más del 30% de lo que cobras, tu precio está mal — o la función es demasiado cara de operar (lo resuelven routing/caching) o demasiado barata para venderla (sube el nivel).
El caso agentic, porque alguien de tu equipo lo va a proponer. Un asistente conversacional realmente útil necesita retrieval, tool calls y memoria multi-turno — en la práctica, de 2 a 5 veces más tokens que una función de resumen por sesión. Con 30 sesiones por usuario al mes, eso es $0.5-2.5/usuario/mes a precios de frontera con caching y routing bien hechos — y más sin ellos. Ahí la regla de margen demuestra su valor: cobra $10/usuario/mes por el nivel de IA, y un costo de modelo de $2.50 deja un 75% de margen — perfecto. Salta el routing y el caching, mira cómo la misma función se come $5, y el nivel queda en números rojos antes de que le pagues al equipo que lo construyó. El costo del modelo es el primer lugar donde muere el margen, y es el más fácil de arreglar: la misma función, con routing y caching, suele ser 40-70% más barata.
Errores comunes que debes evitar
En resumen: cuatro patrones que generan pasivos — guardrails, contexto, lock-in y falta de visibilidad de costos.
- Sin guardrails, directo a producción. Prompt injection, contenido dañino, permisos de herramientas rotos. El enfoque de defensa en capas — filtrado de entrada, protecciones nativas del proveedor, validación de salida, sandboxing de herramientas — es el único que sobrevive al contacto con usuarios reales, y no es opcional una vez que una función toca datos de usuarios.
- Meter todo el contexto. «Solo envía todo» es el error de prompt engineering más caro de 2026. Las APIs de contexto largo son reales, pero la curva de costo es lineal y la de calidad no lo es — recupera lo que necesitas, no subas lo que tienes.
- Lock-in de un solo modelo. Un proveedor, un modelo, sin fallback. Cuando el modelo se deprecia o cambia de precio, tienes dos opciones: pagar o entrar en pánico. El routing con fallbacks convierte eso en un cambio de configuración — la misma disciplina de modelos-como-configuración que hace que las migraciones de proveedor sean aburridas en lugar de heroicas.
- Sin visibilidad de costos. Si no puedes responder «¿cuánto costó la IA por usuario este mes?» el primer día del mes, estás volando a ciegas — y la primera vez que te va a importar es el mes en que la factura se duplica. El registro de uso y la atribución de costos por función son trabajo de configuración, no ideas de último momento; los códigos de error y los rate limits son donde empieza la conversación sobre monitoreo.
FAQ
¿Qué función de IA debería construir primero?
El triage de soporte o el resumen de contenido — mayor frecuencia, resultado medible, alcance acotado. Los moonshots son la segunda función, después de que exista la infraestructura de costos y eval.
¿Cuánto cuesta la IA por usuario al mes?
Una función de resumen bien construida cuesta entre $0.03 y $0.15 por usuario al mes según el nivel de modelo y el caching; una función agentic pesada puede costar entre $1 y $5. La fórmula de la sección de precios te dice la tuya — el costo del modelo es el insumo, no la respuesta.
¿Necesito una base de datos vectorial para las funciones de IA?
Solo para retrieval sobre un corpus privado grande. La mayoría de las primeras funciones no la necesitan. Evalúa long-context y búsqueda simple antes de comprometerte con infraestructura vectorial — la mayoría de los equipos descubren que su primera función necesita una base de datos, no una base de datos vectorial.
¿Debo cobrar por token o por suscripción?
Cobra a los usuarios por suscripción o con paquetes de uso — nunca por token. La facturación por token hace que tus usuarios le tengan miedo a tu función. Internamente, registra todo por token; externamente, abstrae esa complejidad.
¿Cuánto tiempo toma lanzar una primera función de IA?
De dos a cuatro semanas para una función acotada con un codebase existente — si el eval y el monitoreo de costos están desde el primer día. Sin ellos, la misma función toma un trimestre, porque la reconstruirás una vez que descubras que no puedes medirla. ¿Nuevo en la capa de API por completo? Nuestro quickstart te lleva a tu primera llamada en minutos.
¿Puedo usar datos de clientes para hacer fine-tuning de modelos?
No — por defecto, cero entrenamiento con datos de clientes, y verifica los términos de procesamiento de datos de cada proveedor que uses. El cumplimiento normativo es una función; las obligaciones de GDPR y privacidad de datos son la línea base, no el diferenciador, y el rastro de auditoría que construyas para ellas es el mismo que pedirá tu revisión de seguridad más adelante.
Resumen
Cuando agregas funciones de IA a tu SaaS, trátalas como productos con una estructura de costos — elígelas por frecuencia y disposición a pagar, diseña su arquitectura con un backend proxy y routing de modelos, ponles precio con unit economics por encima del 70% de margen, y protégelas con guardrails antes del lanzamiento. Haz esas cuatro cosas y estás agregando un foso; sáltalas y estás agregando un centro de costos con una envoltura con forma de función.
Tu primera función de IA merece unit economics, no una demo. Obtén tu TokSpan API key — incluye $5 en créditos gratis — y ve el costo por función desde la primera request.