Preguntas reales del equipo en el formulario previo. Respuestas pedagógicas con ejemplos del negocio: broker, fondos, research, mesa de operaciones y back office.
Claude no dibuja, pero es excelente para la capa estratégica del manual: definir tono, redactar lineamientos, sistematizar reglas y dejar todo prolijo en un documento usable por la agencia o el equipo interno.
Pensá a Claude como el director de arte que ordena las decisiones, no como el ilustrador. Le pasás referencias (PDFs de marca de competidores, capturas, briefs viejos, una foto del logo actual) y le pedís que extraiga el sistema: paleta primaria/secundaria con códigos hex, jerarquía tipográfica, tono de voz con ejemplos do/don't, reglas de uso del isotipo. Para piezas visuales concretas, lo combinás con un generador de imágenes externo (Midjourney, Adobe Firefly) y Claude te arma el prompt maestro que mantiene consistencia entre piezas.
Para un fondo nuevo de IEB necesitás un mini-manual antes de mandarlo a la agencia. Subís a Claude el manual corporativo de IEB, el prospecto del fondo y dos referencias de cómo Galileo y MegaQM presentan productos similares. Le pedís que devuelva un brief de marca de 2 páginas con paleta, tono ("institucional pero accesible, con foco en el inversor minorista"), tres titulares de ejemplo y una guía de qué evitar. Eso baja a la agencia con la mitad del tiempo de ida y vuelta.
Cuanto más material de referencia le subas al inicio, mejor. Claude trabaja por contraste: con un solo PDF improvisa, con tres referencias bien elegidas sistematiza.
En Cowork (la versión de Claude para empresas) la información que cargás no se usa para entrenar modelos, queda dentro del workspace de IEB y se puede auditar. Es una capa pensada justamente para que áreas reguladas puedan trabajar tranquilas.
Cowork corre sobre la misma infraestructura de Claude pero con un contrato distinto: zero data retention para entrenamiento, controles de acceso por rol y registro de auditoría. Cuando subís un Excel o pegás un texto, Anthropic lo procesa para responderte y lo descarta — no se queda en un dataset. El admin del workspace controla qué integraciones están habilitadas, quién puede crear proyectos compartidos y qué se puede exportar.
El equipo de cumplimiento puede usar Cowork para revisar contratos con clientes institucionales sin riesgo de que ese texto termine entrenando un modelo público. Y back office puede cargar reportes diarios de operaciones para que Claude los resuma sin que esa información salga del perímetro de IEB. Lo único que sigue siendo responsabilidad del usuario es no pegar datos que no deberían ni siquiera estar en una herramienta de IA — DNIs de clientes, claves de cuenta, información sensible bajo Ley 25.326.
El módulo de consumo explica con calculadora cómo se distribuyen los tokens dentro de Cowork por área y proyecto.
Por sí solo, no. Claude es un modelo de texto y código — no genera imágenes ni videos. Pero sí puede dirigir generadores externos y armar piezas visuales completas en HTML/CSS o SVG cuando tiene sentido.
Hay tres caminos según qué necesites. Uno: para imágenes, Claude te escribe el prompt y lo pegás en Midjourney, DALL-E o Firefly. Dos: para diagramas, infografías y dashboards, Claude genera código HTML/SVG directamente y lo abrís en el navegador o lo exportás a PDF — esto es lo que estamos usando para los módulos de capacitación. Tres: para videos, Claude arma el guion, el storyboard y el prompt para Sora o Runway, pero el render lo hace la otra herramienta. La regla: si la pieza es estructurada (gráfico, slide, one-pager), Claude la hace solo; si es fotorrealista, dirige a otro motor.
Para el reporte semanal de research, en vez de pasarle los datos a diseño y esperar dos días, le pedís a Claude un dashboard HTML con los gráficos de los principales activos, el comentario de coyuntura y el branding de IEB. Lo abrís en Chrome, lo exportás a PDF y se publica el mismo día. Para la portada con foto temática, ahí sí abrís Firefly con el prompt que Claude te armó.
No esperes que Claude reemplace a un diseñador para piezas de alta complejidad visual. Pero para todo lo "estructurado y repetitivo" — reportes, dashboards, infografías, mini-sites — es donde más valor agrega.
Hay tres niveles: subir archivos sueltos (lo más simple), conectores oficiales para OneDrive y SharePoint dentro de Cowork, e integraciones vía MCP (Model Context Protocol) cuando necesitás que Claude lea o escriba en planillas de forma automática.
El nivel uno es arrastrar un .xlsx o .docx al chat: Claude lo lee, te responde sobre el contenido y devuelve un archivo nuevo si querés. El nivel dos son los conectores que se activan en Cowork desde el panel de admin — una vez conectados, podés decirle "tomá el último reporte de la carpeta Research/Daily" y Claude lo busca solo. El nivel tres es MCP: un servidor que expone Excel o SharePoint como una API estructurada y le permite a Claude operar como si fuera un usuario más (agregar filas, actualizar fórmulas, etc). Para tareas repetitivas grandes, MCP es lo que escala.
El equipo de mesa que arma cotizaciones diarias mantiene una planilla con activos, precios y márgenes. Con un MCP conectado, cuando entra un pedido de un cliente corporativo Claude consulta la planilla, calcula la cotización con los márgenes vigentes y devuelve la respuesta lista para mandar — sin que nadie tipee dos veces lo mismo. Para casos más simples, como pedirle un resumen ejecutivo de un Word de 40 páginas, alcanza con arrastrarlo al chat.
Empezá por el nivel uno (subir archivos) para entender qué tan bien lee tus formatos. Cuando esa interacción pasa a ser diaria, ahí justifica armar el conector o el MCP.
Tratá a Claude como un par de ingeniería: le pedís que explique, que muestre código, que arme un prototipo funcional y que te lo deje corriendo. Para HTML/CSS, Claude renderiza directamente; para APIs, te da curl/Postman/Python listo para probar.
Para interfaces HTML conviene pedirle "armame un prototipo de una sola página, todo en un archivo, que pueda abrir en el navegador" — Claude devuelve HTML+CSS+JS embebido y lo iterás conversando ("hacé el header más finito", "agregá un dark mode"). Para APIs, le compartís la documentación (un PDF, un OpenAPI, un link) y le pedís ejemplos concretos: "armame el llamado para listar las cuentas activas y parsear la respuesta a un dataframe". Si no entendés algo, no le pidas que te lo "explique" en abstracto — pedile que te muestre el caso real con datos de ejemplo, y aprendés más rápido.
El equipo de tecnología quiere prototipar rápido cómo se vería una pantalla nueva del back office antes de meterla en el roadmap del proveedor. Le pasás a Claude tres capturas del back office actual, el dato de qué nuevos campos hay que mostrar y le pedís un prototipo HTML interactivo. En 10 minutos tenés algo navegable que mostrarle al área usuaria, y recién ahí — con feedback real — pedís presupuesto al proveedor.
Para APIs externas (Bloomberg, Refinitiv, ByMA), pegá la documentación oficial al inicio de la conversación. Sin contexto, Claude inventa endpoints que no existen.
Sí. La API de Anthropic se contrata una vez a nivel IEB y la usás desde donde quieras: backoffice, research, marketing, automatizaciones internas. El consumo se factura por tokens y se puede separar por área con etiquetas.
La API es una clave que cualquier sistema de IEB puede llamar: una macro de Excel, un workflow de Power Automate, un microservicio interno, un bot de Teams. Cada llamada consume tokens y se factura mensualmente. Para gobernarlo, se crean claves separadas por área o proyecto y Anthropic da el detalle de consumo por clave — así contabilidad imputa el gasto donde corresponde sin discusión. Por encima de la API podés montar abstracciones internas: un "endpoint IEB" que cualquier sistema llame sin conocer los detalles del modelo, y el día que cambie el modelo ese contrato interno no se rompe.
Imaginá un endpoint interno `/ia/resumen-research` que toma un PDF y devuelve un resumen ejecutivo. Lo usa la web de IEB para mostrar abstracts a clientes, lo usa el bot interno de Teams para notificaciones rápidas, y lo usa el equipo de marketing para alimentar el newsletter. Una sola clave de API, tres áreas consumiendo, un solo lugar para auditar costo y comportamiento. Si mañana sale un modelo más barato, lo cambiás detrás del endpoint y nadie se entera — solo baja la factura.
El gasto típico de API es bajo si lo medís contra horas de trabajo ahorradas. El error más común es no separar las claves: terminás con un único pozo de tokens y nadie sabe quién quemó qué.
Claude Code es la versión de Claude que vive en la terminal y puede leer, escribir y ejecutar archivos en tu computadora con tu permiso. Para "crear agentes" no programás nada: definís el rol, las herramientas y las reglas en un archivo de configuración, y el agente queda disponible para que lo invoques.
Un agente en Claude Code es una combinación de tres cosas: un prompt de sistema (qué rol cumple, qué tono usa, a qué se dedica), un set de skills habilitados (acceso a archivos, a la web, a una API específica) y un alcance (en qué carpetas o proyectos puede operar). Lo definís en formato Markdown o YAML, lo guardás como un archivo `.md` y desde ahí Claude Code lo carga cuando lo invocás. Los agentes se pueden encadenar: uno hace research, le pasa el resultado al siguiente que escribe el reporte, y el siguiente lo publica.
Para el equipo de research crearías un agente "analista-renta-fija" que cada mañana lee los reportes de los principales emisores, extrae los datos que importan a IEB, los compara con la curva de la semana anterior y devuelve un brief de 200 palabras. Otro agente "publicador" toma ese brief y lo formatea para el newsletter, el sitio y un mensaje de Teams. Quien ejecuta es siempre la misma persona — los agentes le ahorran las dos horas mecánicas de cada mañana.
El módulo de progressive disclosure entra en detalle de cómo Claude Code carga skills en capas y por qué eso baja el consumo de tokens.
Por defecto no, Claude no tiene acceso a feeds de mercado en vivo. Pero le podés conectar fuentes propias (Bloomberg, Refinitiv, ByMA, una base interna) vía API o MCP, y ahí pasa a tener datos al instante.
Claude no scrapea ni se conecta a internet salvo que vos le des una herramienta para hacerlo. Las opciones son: una herramienta de búsqueda web (útil para noticias, sirve poco para cotizaciones tick-by-tick), un endpoint propio que consulte tu proveedor de datos y devuelva el dato ya digerido, o un servidor MCP que exponga el feed como una API consultable. Para cotizaciones de mercado lo correcto es lo segundo o lo tercero — porque tenés contrato y latencia controladas, y porque la responsabilidad legal del dato sigue siendo del proveedor original.
Cuando un cliente le escribe a su asesor "¿cómo está el AL30 hoy?", el asesor podría preguntarle al chat interno y obtener la respuesta sin abrir Reuters. Detrás, Claude llama a un endpoint que IEB armó sobre su feed de ByMA, recibe el dato, lo formatea y lo devuelve con el contexto del último cierre. Ojo: para decisiones de operación seria, la fuente sigue siendo la pantalla del proveedor — Claude resume y conversa, no reemplaza la regulación de tener una fuente oficial.
La pregunta antes de conectar un feed nuevo no es "¿se puede?" sino "¿qué decisión voy a tomar con esto?". Si la decisión es regulada, el feed tiene que mantener su trazabilidad original.
Claude acelera las cuatro etapas: descubrimiento (entrevistas, research, benchmarks), definición (prospecto, fichas, propuesta de valor), prototipado (mockups, simuladores, calculadoras) y comunicación (landing, one-pager, FAQ). No reemplaza al área de producto pero le saca el 70% del trabajo mecánico.
El flujo típico arranca con discovery: le subís a Claude transcripciones de entrevistas con clientes y le pedís que extraiga patrones, dolores, frases que se repiten. Después definición: le pasás benchmarks de productos parecidos en otros mercados y le pedís que devuelva un canvas de propuesta de valor con foco en el segmento de IEB. Prototipado: cuando tenés la idea, le pedís un simulador HTML que el cliente pueda usar para entender qué pasa con su plata. Comunicación: con el simulador funcionando, Claude redacta la landing, las preguntas frecuentes y el guion para el equipo comercial. Cada paso reduce la incertidumbre del siguiente.
Estás cerrando un fondo nuevo de renta fija pensado para inversor minorista que recién empieza. Le pasás a Claude tres benchmarks (el más vendido del competidor, uno premium internacional, uno chico de un comp local), el prospecto en borrador y dos entrevistas con asesores que vendieron productos parecidos. En la misma sesión obtenés: un simulador HTML donde el cliente mete monto y plazo y ve el resultado proyectado, una FAQ de 12 preguntas, un guion de 5 minutos para el call de lanzamiento del equipo y tres titulares para la landing. El equipo de producto valida, ajusta, y va a producción en una semana en vez de cuatro.
El cuello de botella ahora no es generar opciones sino elegir bien entre las que Claude propone. Sumá criterio humano en cada decisión, no solo en la final.
Los tokens son la unidad de cuenta de Claude — cada palabra, número o pedazo de palabra cuesta entre uno y tres tokens. Los skills son módulos de capacidades extra (leer Excel, generar PDFs, llamar APIs) que se cargan solo cuando hacen falta para no quemar contexto.
Pensá los tokens como minutos de teléfono: Claude factura por lo que entra (tu mensaje, los archivos adjuntos, el historial) y por lo que sale (la respuesta). Un PDF de 20 páginas son unos 10.000 tokens; una pregunta corta, 30. El precio depende del modelo: Sonnet es más barato y rápido, Opus es más caro y más capaz para tareas complejas. Los skills son una optimización: en vez de cargar todas las capacidades al inicio (lo que comería contexto antes de empezar), Claude carga solo el skill que necesita cuando aparece una tarea que lo requiere — eso se llama progressive disclosure.
Un asesor que usa Claude para 30 consultas diarias de research consume aproximadamente 200.000 tokens por día — menos de un café por mes en costo, contra horas de trabajo ahorradas. Si el mismo asesor activara un skill de "leer planillas de Excel" al inicio de cada conversación aunque no lo use, gastaría 4.000 tokens extra cada vez sin valor. Por eso los skills se cargan solo cuando aparece un .xlsx, no antes.
Los dos módulos siguientes te explican calculadora en mano cuántos tokens consumen tus tareas típicas y cómo los skills se activan en capas.
En un proyecto compartido todos los integrantes leen y escriben sobre el mismo contexto: archivos, instrucciones, conversaciones. Cada vez que alguien manda un mensaje, Claude reprocesa parte de ese contexto común — por eso el consumo no es la suma de los individuales sino algo intermedio, gracias a que el contexto compartido se cachea.
Un proyecto en Cowork tiene tres capas de contexto: las instrucciones generales (el rol que Claude debe cumplir), los archivos cargados (manuales, datasets, normativa) y las conversaciones individuales que cada miembro va teniendo. Cuando vos abrís una nueva conversación, Claude levanta las dos primeras capas — y como esa porción es idéntica para todo el equipo, Anthropic la mantiene en caché y la cobra a precio reducido. Lo que se factura full son tus mensajes, los archivos que subas en esa conversación específica y la respuesta que obtenés. Por eso un proyecto bien armado es eficiente: el contexto pesado se paga una vez y todo el equipo lo aprovecha.
El equipo de cumplimiento arma un proyecto compartido con la normativa CNV vigente, las circulares del BCRA del último año y los manuales internos de procedimientos — total, 400.000 tokens cargados al proyecto. Diez personas del equipo consultan ese proyecto a lo largo del mes. En vez de pagar 400k tokens × 10 personas = 4M tokens, el cacheo hace que ese material pese sustancialmente menos por consulta. Lo que cada uno paga full son sus preguntas y respuestas. Resultado: el proyecto compartido es más barato que diez chats individuales con la misma información cargada en cada uno.
Los módulos de consumo y contexto te muestran cuándo conviene un proyecto compartido y cómo se distribuye el costo en la práctica.