Simon Willison publicó Understanding ChatGPT Work y en pocas horas el post juntó 248 puntos y 136 comentarios en Hacker News. Antes de seguir, la aclaración honesta: de este anuncio tengo el título, el enlace y la señal del hilo. No te voy a describir funcionalidades que no verifiqué, ni precios, ni límites. Lo que sí puedo darte es cómo se evalúa un producto así cuando todavía no leíste la letra chica.

Por qué importa

El nombre ya es la noticia. Cuando un producto de IA suma la palabra Work, deja de ser una app que alguien paga con su tarjeta y pasa a ser software que toca datos de la empresa: documentos internos, tickets, repositorios, conversaciones de clientes. Ese salto cambia tres cosas de golpe. Cambia quién decide la compra (ya no el dev, sino IT y legales), cambia quién audita el uso, y cambia quién responde cuando algo se filtra.

Hay una segunda señal, más incómoda, y es que el material más votado del día sobre este producto sea un explicador de un tercero. Cuando hace falta que alguien externo te ordene qué es un producto, qué incluye cada plan y qué pasa con tus datos, es porque la superficie oficial no alcanzó. Eso no es un defecto fatal, pero sí es un costo real de adopción: cada persona del equipo que no entiende el modelo de permisos es una fuga potencial.

Qué cambia en la práctica

Si venís usando un LLM como dependencia de una aplicación, un tier corporativo lo convierte en dependencia de la organización. Y eso arrastra trabajo que no es de modelos:

  • Ciclo de vida de identidad. SSO, alta y baja de usuarios, y sobre todo offboarding. Si alguien renuncia el viernes, el lunes no puede seguir teniendo acceso a un asistente conectado a los datos del equipo.
  • Auditoría propia. No delegues el registro de uso al panel del proveedor. Guardá tu propia traza: quién consultó, cuándo, contra qué fuente. Es lo primero que te van a pedir en una revisión.
  • Costos por resultado, no por token. Los planes corporativos suelen facturarse por asiento. La métrica que importa deja de ser el precio por millón de tokens y pasa a ser el costo por tarea efectivamente completada. Son números distintos y el segundo es el único que sirve para justificar la licencia.
  • Frontera de arquitectura. El SDK del proveedor no debería aparecer en tu capa de dominio. Definí un puerto, poné el vendor en el adaptador, y ganás la capacidad de cambiar de proveedor sin tocar reglas de negocio.

Esa frontera se ve más clara con código que con párrafos:

// puerto: el dominio no conoce al proveedor
export interface AsistenteTexto {
  responder(input: { prompt: string; usuario: string }): Promise<string>;
}

// adaptador: acá vive el vendor, y acá se audita
export class AsistenteVendor implements AsistenteTexto {
  constructor(private cliente: ClienteLLM, private auditoria: Auditoria) {}

  async responder({ prompt, usuario }: { prompt: string; usuario: string }) {
    await this.auditoria.registrar({ usuario, hashPrompt: sha256(prompt) });
    return this.cliente.completar(prompt);
  }
}

Son veinte líneas que te compran opcionalidad. Sin ellas, la decisión de compra de este trimestre se transforma en deuda de arquitectura del año que viene.

Cuándo NO usarlo

Si no podés contestar por escrito qué se retiene, por cuánto tiempo y si tus datos entrenan modelos, no lo adoptes todavía. No alcanza con la intuición ni con el resumen de un blog, incluido este. Esa respuesta tiene que venir de la documentación oficial y del contrato, y hoy no la tengo verificada para este producto.

Si tu caso de uso es un solo flujo automatizado, un tier colaborativo es sobreprecio. Un pipeline que clasifica tickets no necesita asientos, espacios compartidos ni administración de equipos: necesita una API y un presupuesto. Pagar por colaboración cuando no hay nadie colaborando es la forma más común de inflar el costo de la IA en una empresa chica.

Si trabajás con datos regulados o con clientes que tienen cláusulas de subprocesadores, frená. Ahí el bloqueante no es técnico: es el acuerdo de tratamiento de datos firmado y la lista de subprocesadores actualizada. Sin eso, cualquier piloto es un riesgo que asumís vos sin haberlo dicho en voz alta.

Si el proceso que querés reemplazar hoy es determinista y funciona, no lo toques. Cambiar una validación que falla de forma predecible por un modelo que falla de forma creativa es un mal negocio, por más que la demo se vea bien.

Y el caso meta: si la mejor fuente disponible sobre el producto sigue siendo un explicador de un tercero, no es momento de firmar un plan anual. Es momento de leer, probar en un sandbox sin datos reales y esperar a que la documentación oficial se estabilice.

Qué haría yo hoy

Leería el post de Willison completo y, sobre todo, el hilo de Hacker News: en ese tipo de discusión aparecen los límites que el material oficial no menciona. Después armaría un documento de una página con cinco preguntas para el proveedor (retención, entrenamiento, permisos, exportación de datos, salida del contrato) y no avanzaría hasta tenerlas contestadas por escrito.

Si las respuestas cierran, un piloto de treinta días con un solo equipo, con la capa de auditoría propia desde el día uno y una métrica definida antes de empezar. Si no cierran, lo dejo anotado y sigo con la API pelada, que ya sé exactamente qué hace y cuánto me cuesta. Adoptar tarde una herramienta buena cuesta poco. Adoptar temprano una herramienta que no entendés cuesta bastante más.