capas

Tenemos un par de aristas para el mismo problema, la ecuación que se viene es la siguiente: cuál es la o las licencias de LLM que se debe asignar a cada usuario en una organización y/o cuál es el nivel de consumo óptimo promedio que se le debe limitar.

La inquietud es sencilla. La forma de responderlo no existe hoy, pero la creatividad y la experiencia otorgan una respuesta plausible. Asignar productos (Gemini, Copilot o Claude) según caso de uso, algo así como: Gemini para análisis duro, Claude para ofimática y diseño estratégico, Claude Code para usuarios técnicos avanzados, Claude Cowork en pausa para las corporaciones hasta que deje de estar en desarrollo —ajaj. Copilot para los que aún no se han dado cuenta de lo malo que es Copilot y/o para los usuarios de poca intensidad.

Para entender el contexto de esta ecuación es necesario entender que las suscripciones operan de la siguiente manera, vista rápida:

• Copilot, dentro de licencias Teams. Además Microsoft está desesperado porque sus clientes usen este producto entonces siempre está armando bundles para amarrarte y quedar muy por debajo del precio lista (USD 30 mes para Copilot 365, la versión "PRO" de Copilot básico. Copilot básico es el que está embebido en Teams y esa es otra suscripción).
• Gemini en Google Workspace, "consumo infinito". Google tiene mucho cómputo para regalar. Usas Gemini App (www.gemini.google.com) y NotebookLM. Y ya. Precio lista de la licencia estándar
  • Para cuestiones técnicas: API Keys o Vertex AI. Esto todo a través de Google AI Studio, que finalmente es todo a través de Google Cloud Platform (GCP). El modo de pago acá es por consumo (o "vía API" como se suele decir).
• Gemini Enterprise, alternativa para los que no tienen Google Workspace, pero sí tienen GCP. Valores muy similares. Una versión paria de Gemini en Workspace, con promesas de estar equivalente muy pronto. Y con promesas de agentes y grounding de datos de tus fuentes empresariales (Sharepoint, SAP, GCP, Slack, Outlook, Drive, etc). No he visto ningún producto bueno aquí hasta la fecha, aunque tiene más potencial que Gemini en Workspace. Valor bastante similar, licencia estándar a USD 30 mes. En la versión de chat, tienes "consumo ilimitado".
• Claude. Claude es más honesto con su cómputo y su pricing. Claude saca updates, features y productos todas las semanas, actualmente dominan el relato. Y lo mejor de todo es que sus features funcionan muy bien y la mayoría de las veces a la primera (no como en los otros que se mencionaron antes, en donde el resultado requiere de muchas iteraciones y/o es menos perfecto que el resultado de Claude).
  Claude ofrece dos formas principales de contratación:
  • Team. Un máximo de 150 asientos, por USD 20 mes cada uno. Consumo limitado, pero suficiente para un usuario final. Esto incluye el gran feature de los proyectos compartidos, así como acceso a Cowork, Code, complementos para Office, el de Excel es muy bueno —y mucho mejor que el de Copilot by the way. Y Design que está en preview aún. Dispatcher también... Skills, Contexto organizacional, "Ask" a tu empresa, Conectores, etc. Algunas limitantes de gobernanza, pero bastante decente. Puedes agregar consumo adicional prepagando por este y asignándolo a ciertos usuarios o grupos de usuarios.
  • Enterprise. Consumo vía API, prepagado. Muchas features de gobernanza, granularidad, métricas de uso granulares, asignación granular de consumo límite por mes a cada usuario. A mi ver, es el más caro pero el más completo para lo que exigiría un área de tecnología seria en una corporación. No es naturalmente todas las features de Team más lo mencionado anteriormente, ojo con eso. Pero, sí tiene los mismos tools y features que Team, salvo que el consumo es vía API. Puede que, haya un mix entre Team y Enterprise, pero eso debe resolverse con el equipo de ventas de Antrhopic, que nunca responde. Y esta es la parte más dura de toda la cuestión.

Para entender por qué es importante manejar este contexto debemos combinar un par de capas.

gobernanza

Vale una arqueología rápida.

Estaba la ofimática. Luego las soluciones de baja complejidad. Luego las de complejidad media y alta. Finalmente los sistemas críticos y los sistemas operativos. No me acojo a una definición técnica, es entendimiento estándar de arquitectura tecnológica. Cada capa tenía sus guardrails, sus procesos de validación, sus responsables. Imperfectos, pero existían.

Hoy se suma una capa nueva. Soluciones construidas con AI, de bajo código, que abarcan las tres primeras capas simultáneamente. Cualquier usuario con acceso puede construir ahí. Y lo está haciendo. Ahora mismo.

Esa capa no tiene gobierno real. No porque nadie haya intentado gobernarlo —es que no es gobernable en su totalidad. Hace más de un año que existen soluciones de orquestación que prometen concentrar todos los flujos con AI en un solo punto de control. Son útiles. Son parciales. No cubren lo que no saben que existe. Y lo que no saben que existe es, precisamente, lo que se construye en la periferia, con entusiasmo, con buenas intenciones, sin documentación —generalizo quizá, pero tampoco estoy lejos. Flujos que involucren cuentas personales entrecruzadas con con soluciones entregadas por la empresa son imposibles de tracear, al menos no el 100%.

Ningún usuario tiene idea completa de todo lo que está construyendo ahí. Ningún responsable de TI lo sabrá nunca del todo. Y no es pesimismo, es simplemente la naturaleza de una capa que creció más rápido que cualquier modelo operativo diseñado para contenerla.

Ya no se pueden vender ilusiones de gobernanza. Si antes ya era difícil, para qué decir ahora.

adopción

Hay una fantasía que opera silenciosamente detrás de cada nueva adopción tecnológica: la del resultado desmedido. Esta fantasía es inocente.

Seguro hay otras analogías mejores, pero insisto en la fantasía de encontrar el pozo petrolero: la idea de que en algún momento, usando la herramienta correcta, va a aparecer un beneficio desmedido, transformador, proporcional al entusiasmo con el que se adoptó. Y mientras tanto, el usuario espera. Usa. Delega. Y sigue esperando.

El problema no es la fantasía en sí misma. El problema es que se activa sin contexto, sin criterio, y —cada vez más— sin consecuencias visibles en el corto plazo. Lo que la hace peligrosa no es que sea falsa. Es que a veces es verdad. Para algunos. En condiciones muy específicas. Y eso es suficiente para que se sostenga. Aquí Claude le hace brillar los ojos al usuario final.

Simplifiquemos, aunque toda simplificación ofende algo.

Claude —o cualquier suite de herramientas GenAI de esta generación— es una motosierra. No en el sentido dramático. En el sentido literal: es una herramienta de alto poder, diseñada para tareas que requieren fuerza, precisión y criterio sobre cuándo usarla y cuándo no.

Hay usuarios que necesitan un cuchillo para echarle mantequilla al pan. Hay usuarios que deben abordar un proceso empresarial completo, con dependencias, con datos sensibles, con consecuencias. Y en la práctica, a todos se les está entregando la misma herramienta.

el usuario funcional y la adopción

Vuelvo al usuario funcional. Porque ahí está el nudo.

No es el usuario técnico el más expuesto. El usuario técnico y con criterio, entiende lo que está cediendo cuando autoriza permisos, cuando comparte contexto, cuando conecta herramientas. Puede no estar de acuerdo con todas las implicancias, pero las ve.

El usuario más vulnerable es el que no sabe que está cediendo algo.

Las herramientas GenAI vienen con contexto general by default, cada vez más y ya he insistido bastante sobre esto. El usuario, en su ansiedad por adoptar, lo autoriza. La funcionalidad responde y responde bien. El copiloto cognitivo que emerge se siente útil, cercano, casi personal. La sensación de tener un asistente que te conoce es funcionalmente real. Y en ese encantamiento, la delegación ocurre sin que nadie la haya decidido explícitamente.

No hay malicia en ningún punto de ese proceso. Hay inocencia. Hay FOMO. Hay la misma fantasía del pozo petrolero, ahora retroalimentada por resultados reales que confirman que algo está pasando, aunque no se sepa exactamente qué.

El usuario que más riesgo corre no es el ignorante absoluto —ese ni siquiera llega a usar la herramienta (o sólo usa Copilot, permítaseme el chiste). Es el usuario parcialmente informado, funcionalmente satisfecho, que no tiene razones visibles para detenerse a preguntar qué está construyendo y a qué costo.

El grueso está recién conociendo la herramienta. Para muchos, esto todavía suena a problema futuro.

Pero, esa es exactamente la lógica que hace que el problema se instale sin resistencia. Cuando el grueso llegue a donde esto apunta, la capa ya va a estar construida, tener peso gravitacional propio y, aunque les duela a los puristas de TI, sin gobierno. Los flujos ya van a existir. Las dependencias ya van a ser reales. Y nadie va a saber con certeza qué hay ahí, cuánto abarca, ni cómo se desmonta.

No tengo una solución prolija para esto. Quien diga que la tiene, probablemente quiere vender algo.

Lo que sí tengo es una postura: si la capa es ingobernable en su totalidad, la respuesta no es más gobernanza, la respuesta es criterio distribuido. No se puede controlar lo que se construye. Sí se puede intentar que quienes construyen tengan claridad de qué están haciendo y qué están cediendo. Eso cambia la estrategia de adopción de manera fundamental: no es adopción masiva ni restricción total. Es saber con quién vale la pena invertir en que construyan bien y tener la honestidad de reconocer que no son todos. Más adelante me referiré brevemente a este punto, dado que como vengo insistiendo en textos anteriores la tendencia del cerebro es buscar lo fácil, pero definitivamente se mueve tan rápido el escenario, que no hay forma de hacerlo fácil para el usuario funcional.

La motosierra en manos equivocadas no destruye por maldad. Destruye por entusiasmo. Y el entusiasmo, en este momento, sobra.

el nuevo workspace

Se habló de la muerte del SaaS. Falta aún. Sin embargo, es necesario repasar esta idea. Porque el workspace + las plataformas de low code/no code 1. permitían gobierno, 2. no son sólo SaaS, 3. involucran diversos productos y suscripciones.

A mi ver, la pista queda despejada para los proveedores de LLM dado que pueden consolidar todas esas funcionalidades desde la misma interfaz, al menos como producto para las corporaciones y empresas, pueden empezar a competir con los proveedores de plataformas de trabajo. No estoy diciendo que los van a matar, es probable que muchos clientes usen las bondades de las dos (LLM y workspace tradicional), pero quizá el grueso de la construcción y del trabajo, en términos de tiempo de uso, se concentre en el LLM y las herramientas de Office, Browser, Power Platform, Power BI, etc., y los símiles de éstas, se utilicen cada vez menos.

El "nuevo workspace" no tiene esa fricción. El usuario construye desde el chat. Desde el mismo lugar donde pregunta, redacta, analiza. La línea entre usar y construir desaparece.

La capa sin gobierno crece más rápido de lo que cualquier estimación anterior suponía, porque el punto de entrada ahora es este nuevo workspace, no una herramienta especializada. Y este workspace tiene potencial de volverse lo cotidiano. Consideremos además que el proveedor de LLM está constante y unilateralmente definiendo qué es lo que incluye el seat básico y qué no, como si no tuviésemos suficientes problemas.

Hay otra capa más profunda: si el workspace es "el nuevo Power Platform", entonces el dato personal, el contexto laboral, el flujo de trabajo —todo eso ya está adentro por default. No porque el usuario lo haya cedido conscientemente. Porque es donde trabaja. Power Platform tenía fricción. Había que ir a otra interfaz, aprender otra lógica, pedir permisos. Eso actuaba como filtro natural —no perfecto, pero existía.

No es solo que la capa sea ingobernable —es que el workspace mismo se está desplazando. Antes el workspace era Office, Teams, el navegador. Ahora es Claude, Gemini, Copilot. Y con ese desplazamiento viene algo que Power Platform nunca logró del todo: que el usuario construya dentro del mismo espacio donde trabaja, sin fricción, sin salir, sin darse cuenta de que está construyendo.

volvamos a la ecuación

Entonces, teniendo en cuenta las capas, supongamos dos cosas: el estándar de consumo será vía API, la interfaz de chat de LLM y su respectiva plataforma se transforma en el nuevo workspace.

Se dijo que la respuesta debía ser educar en criterio. Pero, además se debe educar técnicamente. Esto porque un usuario que está utilizando un LLM vía API debe saber cuándo pasar de Opus 4.7 a Haiku y viceversa. Esto porque un usuario con criterio debe saber cuándo debe dejar de iterar. Esto porque un usuario con criterio y más de una licencia debe saber cuándo usar cada una. Sin embargo, ya se ha hablado bastante de la naturaleza humana y la tendencia a buscar la falta de fricción.

Y lo más evidente, que se refuerza para que quede dicho, es que la tentación a la delegación cognitiva es cada vez más alta. Más alta cada semana. El workspace que no tiene fricción es el más atractivo para la programación natural de nuestros cerebros humanos.

Si la plataforma pasa a ser el nuevo workspace, todo tendrá mucho consumo. Imagino consultas del tipo "considerando todo lo que sabes de este proyecto y todo el contexto que tienes entonces dime cuál es la mejor estrategia frente a este escenario", esa consulta costará más de un dólar. Si un usuario tiene USD 20 mes asignados, entonces no podrá hacer más de 20 consultas en un mes. La adopción se va al carajo, el usuario prefiere incluso pagarse una licencia individual y vuelve a perderse la fantasía de la gobernanza y el compliance. ¿Cuál será el promedio mensual por usuario? ¿USD 120? No sé, números al azar pero no tan descabellados.

Además, la comunicación y educación masiva se vuelve un lío porque ya no puedes decir, por ejemplo, tips simples del tipo "prefiere siempre los modelos razonadores".

Finalmente, unos pelos a la sopa, el consumo de LLM no desplazará necesariamente la suscripción a licencias estándar tipo Microsoft 365 E3 o E5, o Google Workspace Estándar, o qué sé yo. Las áreas que controlamos estas herramientas ya no tendremos que exigir casos de uso para la asignación de una licencia sino también casos de negocio y forecast del consumo anual en tokens, cuestiones de las que el usuario final ni maneja estadística ni está entrenado para. Mientras que Claude sigue publicando nuevos features que aumentan la ansiedad y la presión de parte de los usuarios.

Nos viene mucho esfuerzo en estar justificando por qué necesito presupuestar USD 150 mes en consumo de tokens para mí y para cada uno de los miembros de mi equipo.

Que Claude nos ayude.