Los productos de IA deben resolver problemas, no demostrar IA

Un producto de IA debe resolver un problema que alguien ya tiene, no exhibir que hay un modelo detrás. Si quitas el modelo y el resultado no cambia, no es una capacidad: es una demo. El criterio es el resultado. La etiqueta no.

Escribo esto como Jorge Cortés, ingeniero de producto en Santiago. La nota ya estaba en este sitio. La defiendo con un producto mío y con el trabajo que tomo en sistemas IA.

¿Por qué demostrar IA no es un producto?

Un producto existe para que alguien termine un trabajo. Reservar. Aparecer. Leer un año de chat como números. Ese trabajo estaba antes del modelo. Si el modelo no lo mueve, es adorno.

El encargo llega a menudo como «agrégale IA». Eso no es un problema. Es un disfraz. Entender antes de construir es nombrar el trabajo, no el vendor.

Demostrar IA tiene una forma que reconozco: una caja de chat en la portada que no es dueña de ninguna decisión; un sello «powered by AI» sobre un histograma; un POST del archivo del usuario a un modelo hospedado porque la home prometió inteligencia; un notebook que nunca se volvió una URL que alguien pueda abrir dos veces.

Pueden parecer trabajo. No son el producto. El producto es el trabajo que sigue existiendo el martes, cuando la demo está cerrada.

No argumento contra los modelos. Argumento contra poner el modelo donde debería estar el problema. En Build, la capa de IA es una capacidad cuando cambia el resultado — nunca una demo.

Reducir hasta que se vuelva obvio cambia la pregunta. No es «qué modelo». Es «qué cambia para el usuario si este cálculo existe». Si la respuesta es «la landing se ve más seria», no hay producto.

¿Cuándo un modelo cambia el resultado?

Un modelo cambia el resultado cuando se cumplen tres cosas a la vez.

Primero: hay una decisión nombrada. Aceptar o rechazar. Ordenar. Generar un texto que el usuario no podría escribir desde una tabla. Clasificar un caso que las reglas etiquetan mal. Si no puedo nombrar la decisión en una frase, no tengo un lugar para un modelo.

Segundo: la estadística y las reglas fallan esa decisión con una calidad que el producto no puede defender. Conteos, umbrales, sumas ponderadas, regex y un parser son más baratos y más claros. También alcanzan más veces de las que admite un encargo. No asciendo un score a red neuronal porque a la landing le gusta la palabra inteligencia.

Tercero: el coste, la latencia y la privacidad todavía lo permiten. Un modelo correcto que filtra el archivo, tarda doce segundos o cuesta más que el crédito que pagó el usuario no es una capacidad. Es una restricción que ignoré.

Si falla cualquiera de las tres, no lanzo un modelo. Lanzo el cálculo que sí mueve el trabajo.

«Cambia el resultado» no es «suena más inteligente en un roast». Es: el usuario decidiría otra cosa, o terminaría el trabajo, solo si ese cálculo existe.

Un mapa de calor no necesita un modelo. Un modelo cambiaría el resultado si el producto tuviera que generar un párrafo que no es una plantilla, y ese párrafo fuera el trabajo. No evidencié que WspWrapped haga eso. No lo voy a afirmar.

¿Qué métricas de WspWrapped necesitan un modelo?

Construí WspWrapped para que un export de WhatsApp se vuelva más de 30 métricas de conversación sin guardar el texto de los mensajes. El producto en vivo es wspwrapped.online. El parser corre en memoria. Solo persisten agregados. La privacidad es la arquitectura.

No partí de «ponerle IA a los chats». Partí de un archivo que el usuario ya tiene. Las preguntas son el trabajo: quién escribe más, quién empieza, quién contesta a las 3am, quién se calla, quién borra. Los datos están en el export. El trabajo es convertirlos en números sin convertirlos en una base de mensajes ajenos.

Si persisto texto, me convierto en un almacén de datos íntimos. Si hago POST del transcript a un LLM hospedado, transmito ese almacén. El FAQ dice que no guardamos el contenido de los mensajes. Una demo que manda el chat a un vendor pelea con esa frase.

Parto las superficies de la landing en dos pilas. Esta partición es un criterio. No es una afirmación sobre cada línea de código en producción. Donde no evidencié un modelo, no voy a inventar uno.

Estadística o reglas. Conteos, mapas de calor, tiempos de respuesta, emojis, horas de búho, double-texting, mensajes eliminados cuando el export trae lápida, iniciativa después de un hueco. Ghosting, tal como lo vende la landing, es un umbral sobre silencios, no un clasificador que yo haya documentado. Interest Level se describe como tiempos de respuesta, iniciativa y engagement: features de timestamps y remitentes. Ninguna necesita un modelo. Un sello de IA sobre un mapa de calor es demostrar IA encima de un conteo.

Método que no asciendo sin evidencia. La landing también vende Couple Dynamics, Compatibility en cinco dimensiones, Romance Score, AI Predictions, The Roast, Psychological Insights. Compatibility es un score: suma ponderada o modelo. AI Predictions es copy: el futuro del chat según patrones detectados por inteligencia artificial. The Roast puede ser una plantilla sobre features o una completion de un LLM. No nombro un vendor. No publiqué aquí el runtime de esas superficies. Si existen, corren sobre agregados y features en el mismo request, o son plantillas. No sobre el transcript. Features adentro, texto afuera.

Esa es la misma regla que vendo en sistemas IA: el modelo es una capacidad dentro de un producto con contrato de datos. No es la home.

El parser es la ingeniería difícil. Si asumo un solo formato de export, invento participantes. El arreglo de un mal parse es un mejor parse, no un modelo. El modelo, si existe, queda río abajo de un archivo que ya convertí en números.

¿Por qué el coste, la latencia y la privacidad deciden antes que el modelo?

Un reporte de consumo tiene precio. Un crédito es un reporte completo. Tres créditos cuestan $2.99. Diez créditos cuestan $4.99. Los créditos no vencen. No hay suscripción. El uso es episódico: un chat, una vez, para una story.

Si cada reporte llama a un modelo hospedado sobre el transcript entero, se rompen tres cosas.

Coste. El usuario pagó un pack, no un presupuesto de tokens. Un grupo largo son decenas de miles de líneas. Una completion sobre ese texto puede costar más que el crédito. No publiqué el costo de inferencia. No necesito una estadística de terceros para saber que los tokens no son gratis y que $2.99 por tres reportes es una restricción.

Latencia. La landing dice métricas en segundos. Es una afirmación de producto, no un benchmark que yo haya publicado. Un parse más histogramas puede cumplirla. Un ida y vuelta a un modelo puede no. Una tarjeta que llega cuando el usuario ya cerró la pestaña no es una tarjeta. La latencia es si el trabajo termina mientras la intención sigue ahí.

Privacidad. Un chat personal no es telemetría. Si persisto el texto, opero un almacén de datos íntimos. Si mando el transcript a un vendor, muevo ese almacén. El FAQ tiene que seguir siendo cierto: parsear en memoria, persistir agregados, tirar el texto. Una métrica nueva no se recalcula sobre reportes viejos. El usuario vuelve a subir.

Estas tres no son diapositivas de ética. Son restricciones de producto. Si el modelo viola una, no «le agrego IA después». Cambio el feature hasta que la restricción aguante, o corto el feature.

Tiempo y memoria serverless son el mismo sobre. Publico en Vercel. Un chat de 50MB es un export real. Un modelo que necesita el archivo entero en un prompt empeora ese sobre.

El contrato de datos se escribe antes de elegir el modelo. WspWrapped puede recordar números. No puede recordar oraciones. El auth es una billetera para créditos y para una URL para compartir, no una réplica del export. Lo que un producto puede enviar a un modelo es una decisión de Think, por escrito, antes de Build.

¿Cómo se diseña un feature como capacidad y no como demo?

«IA como capacidad, no como adorno» ya está en este sitio. En un feature tiene secuencia.

Nombrar el trabajo, no el stack. El trabajo de WspWrapped es convertir un export en un reporte y una tarjeta 9:16. No es «conversa con tu chat». Una caja de chat demostraría IA. La tarjeta es el producto.

Poner el modelo, si existe, detrás de una decisión nombrada. Ejemplo de decisión: generar un párrafo de roast a partir de features, en el mismo request, sin el transcript. Ejemplo de no-decisión: estampar «IA» sobre un mapa de calor. Si no puedo escribir la decisión, no arriendo un modelo.

Diseñar el contrato de datos primero. Si el feature no puede vivir con ese contrato, el feature no entra. No se afloja el contrato para que quepa la demo.

Mostrar el trabajo, no la maquinaria. Si una superficie es una plantilla, no debería llevar sello de IA. Si es un modelo, debería decir que corre sobre features, no sobre el transcript. Una demo necesita el sello. Una capacidad necesita el resultado. El H1 de WspWrapped habla del chat y de la verdad en el archivo, no del modelo.

Un feature de IA que no puede nombrarse sin la palabra IA casi nunca es un feature. Primero el problema. Después el cálculo. Después, si hace falta, el modelo.

Cómo lo aplico

Cuando un encargo dice «agrégale IA», corro esta lista. La uso en mis productos. La uso cuando tomo trabajo en sistemas IA.

1. 01/

   Escribir el trabajo del usuario en una frase. Si la frase es «mostrar que usamos IA», parar. Todavía no hay producto.

2. 02/

   Escribir la salida: un número, un ranking, un documento, una tarjeta. Nombrar quién la usa y cuándo.

3. 03/

   Producir esa salida con parseo, conteos, umbrales o una fórmula. Lanzar eso si ya termina el trabajo.

4. 04/

   Preguntar si un modelo cambiaría esa salida de un modo que el usuario pueda ver. Si no, el modelo es una demo. No agregarlo.

5. 05/

   Si sí, nombrar la decisión que el modelo puede tomar. Escribir lo que nunca debe conservar. Ese es el contrato de datos.

6. 06/

   Contrastar el coste con el precio que paga el usuario, la latencia con el momento de la intención, la privacidad con el archivo que entregó. Si uno falla, cortar el modelo o cambiar el feature. No esconder el fallo en un vendor.

7. 07/

   Meter la capacidad dentro de la superficie del producto — el reporte, la reserva, la página — no en una URL de demo aparte.

8. 08/

   Etiquetar estadística como estadística. Etiquetar salida de modelo como salida de modelo. No vender un histograma como inteligencia.

La lista es corta a propósito. Si un paso necesita una diapositiva, el problema sigue sin nombrar.

Un producto con un modelo sigue siendo un producto. El modelo es una capa. Gana su lugar cuando cambia el resultado de un trabajo que alguien ya tenía, bajo un coste, una latencia y una privacidad que el producto puede sostener. WspWrapped es el caso que puedo mostrar: entra el archivo, salen números, no se guarda un mensaje. Si una superficie lleva etiqueta de IA, igual tiene que obedecer ese contrato. El resto es una demo. No lanzo demos. Lanzo el trabajo.