# Fabián Delgado — fabiandelgado.uy ================================================================================ PAGE: Inicio - Fabián Delgado SOURCE: source/index.html.erb ================================================================================ Consultoría en IA · Uruguay y LATAM Inteligencia artificial para empresas y gobierno en Uruguay. Ex-Tech Lead en AGESIC . Engineering Manager con +15 años construyendo sistemas críticos en Rappi , Tiendamia , Ueno Bank y Discovery Latam . Consultoría en IA aplicada, agentes y automatización para organizaciones que necesitan resultados medibles, no promesas. En 2015 implementé la norma UNIT 1215 de Accesibilidad Web en tramites.gub.uy . Diez años después, construyo un MCP que permite a agentes de IA operar ese mismo portal. Mismo trámite, distinta capa. Conversemos un proyecto Ver proyectos Inscripto en RUPE · Especialista en Accesibilidad Web (AGESIC) · Expositor UNIT 2015 · Co-creador de ollapopular.uy · Montevideo, Uruguay Trayectoria en sistemas críticos Ueno Bank Rappi Tiendamia AGESIC Discovery Latam Servicios Tres formas de trabajar conmigo Cada servicio es un entregable concreto, no consultoría abierta. Empezamos chico, validamos, escalamos. Diagnóstico de oportunidades IA Taller de 1-2 días + informe priorizado de 3-5 procesos automatizables con IA en tu organización. Para cuando todavía no sabés por dónde empezar. Ver detalle → Desarrollo de agentes de IA y MCPs Construcción de servidores MCP y agentes que conectan modelos (Claude, GPT) con tus sistemas internos: trámites, BD, APIs. End-to-end o sumándome a tu equipo. Ver detalle → Auditoría y gobernanza de IA Revisión técnica + cumplimiento alineada a la Estrategia Nacional IA 2024-2030 y al decreto de sandboxes. Para sector público o empresas reguladas. Ver detalle → Proyectos Construyo y mantengo, no solo asesoro Cuatro proyectos propios que respaldan lo que digo: dos SaaS en producción, un open source en Maven Central, y un MCP para gobierno en desarrollo. Open source · Go · MIT MCP para tramites.gub.uy Servidor Model Context Protocol en Go que usa los datos abiertos de AGESIC para que agentes de IA consulten trámites del Estado uruguayo con fuentes verificables. Ver proyecto → SaaS en producción · desde 2015 DobleD Co-fundador. Plataforma B2B de cartelería digital y gestión de filas para retail, salud, gastronomía y financieras. Equipo y soporte 100% Uruguay. Visitar dobled.com.uy → SaaS · Developer tools Nurbak Fundador. Nurbak Watch: monitoreo de APIs para Next.js. Combina checks externos desde 4 regiones con ejecución interna en el proceso. Detecta fallas que monitores tradicionales pierden. Ver proyecto → Open source · Maven Central ciuy Librería Java open source para validación de cédulas de identidad uruguayas. Documentación en español, integración mínima. Ver en GitHub → Por qué Fabián Trayectoria pública verificable, no claims Ex-Tech Lead AGESIC (2018-2022) Cuatro años liderando equipos en la Agencia de Gobierno Electrónico de Uruguay. Unificación de +70 portales gub.uy. Sistemas críticos COVID-19 (Certificados de Vacunación) en alta concurrencia. Especialista AGESIC en Accesibilidad Web Expositor oficial en el Primer Seminario Internacional sobre Normalización y TIC de UNIT (2015) presentando la implementación de la norma UNIT 1215 en tramites.gub.uy. Contribuyente Drupal con foco accesibilidad / W3C. +15 años en sistemas críticos Engineering Manager actual en Ueno Bank. Premio "Golden Mustache" 2022 en Rappi. Migración monolito → microservicios Golang en Tiendamia. Discovery Latam. IA aplicada + Ciberseguridad ML/LLMs aplicados a problemas reales, no demos. Máster en Ciberseguridad en curso (VIU – Universidad Internacional de Valencia). SOC 2 / ISO 27001. Doble lente para venderle al Estado y a Fintech. Inscripto en RUPE Habilitado para facturarle a cualquier organismo del Estado uruguayo desde día uno, sin esperas administrativas. Preguntas frecuentes Lo que más me preguntan ¿Para qué tipo de organización trabajás? Empresas medianas en Uruguay y LATAM (B2B), y organismos del Estado uruguayo (B2G, inscripto en RUPE). El denominador común: organizaciones que necesitan resultados medibles con IA, no demos. ¿Cuánto cuesta un primer trabajo? Diagnóstico inicial: 1-2 semanas. Piloto del primer caso: 2-4 meses. Auditoría de IA: alcance variable. Cada caso se cotiza específicamente: agendá una llamada de 30 minutos sin compromiso y armamos un presupuesto con números concretos. ¿Cuánto tarda en mostrar valor un proyecto de IA? Si el caso está bien elegido y los datos están accesibles: 6-12 semanas para los primeros resultados. 3-6 meses para tener métricas sólidas. Si después de 6 meses no hay valor medible, el problema no es la IA — es el caso elegido o la implementación. ¿Trabajás solo o con equipo? Para diagnóstico, validación de hipótesis y pilotos chicos, trabajo solo o con un ingeniero de apoyo. Para proyectos más grandes, armo equipo a medida con colegas de confianza (Uruguay y LATAM) según el stack y el dominio. ¿Qué tecnologías usás? Modelos: Claude (Anthropic), GPT (OpenAI), Gemini (Google), modelos abiertos (Llama, Mistral) cuando hay restricciones de datos. Integraciones: cada vez más vía Model Context Protocol (MCP) . Stack típico: Python/Go/TypeScript, AWS/GCP/Azure, observabilidad con Langfuse/Helicone. ¿Trabajás presencial en Uruguay o solo remoto? Las dos modalidades. Para proyectos en organismos del Estado uruguayo o empresas en Montevideo, hago reuniones presenciales clave. La mayoría del trabajo es remoto, sincronizando con tu equipo en horario LATAM. ¿Estás evaluando IA para tu organización? Una llamada de 30 minutos para entender tu caso, sin compromiso. Si encaja, armamos un piloto. Si no, te oriento hacia donde tenga más sentido. Agendar llamada Escribir un email ================================================================================ PAGE: Agentes de IA: qué son, qué no son, y cuándo usarlos en tu empresa SOURCE: source/blog/agentes-de-ia-empresas.html.erb ================================================================================ 18 de abril de 2026 · 9 min de lectura Agentes de IA: qué son, qué no son, y cuándo usarlos en tu empresa Hay tres palabras que se mezclan: "chatbot", "RPA", "agente de IA". No son lo mismo. Esta guía explica la diferencia, cuándo cada uno tiene sentido, y cómo arrancar con un agente sin tirar plata. Qué es un agente de IA Un agente de IA es un sistema que combina un modelo de lenguaje (Claude, GPT, Gemini) con herramientas externas — APIs, bases de datos, navegador, sistema de tickets — y un objetivo. A diferencia de un chatbot, no solo responde: actúa . Decide qué herramienta usar, en qué orden, evalúa el resultado y si hace falta, vuelve a intentar. Ejemplo concreto: un agente de soporte que recibe una consulta de un cliente, la clasifica, busca el historial del cliente en el CRM, identifica si hay un caso similar resuelto, redacta una propuesta de respuesta, y solo escala a humano si no logra resolver con confianza. Diferencia con chatbot, RPA y otros conceptos Chatbot vs agente de IA Un chatbot tradicional sigue un árbol de decisiones predefinido. "Si dice X, responde Y". Funciona bien para casos cerrados (preguntas frecuentes, reservas simples), pero rompe cuando la consulta sale del guion. Un agente entiende lenguaje natural, razona sobre la consulta, y puede manejar casos que nunca vio antes — siempre que tenga las herramientas adecuadas. RPA vs agente de IA RPA (Robotic Process Automation) automatiza tareas repetitivas siguiendo reglas estrictas: copiar datos de un sistema a otro, llenar formularios. Es muy bueno cuando el proceso está bien definido y los inputs son predecibles. Un agente agrega flexibilidad: puede manejar inputs ambiguos, decidir qué hacer en casos no previstos, y mejorar con el tiempo. Costo: es menos predecible y más caro de operar. Regla útil: si podés escribir las reglas en un Excel, usá RPA. Si las reglas cambian seguido o tienen excepciones que requieren juicio, usá agente. Asistente vs agente Un asistente ayuda a un humano a hacer su trabajo (Copilot, ChatGPT). El humano queda en el loop. Un agente ejecuta el trabajo autónomo o semi-autónomo. La diferencia importa para gestión del cambio, responsabilidad y compliance. Casos donde un agente funciona bien hoy 1. Atención al cliente Tier 1 Triaje de consultas, respuestas a preguntas frecuentes, escalamiento a humano cuando hace falta. Funciona bien cuando hay buena documentación interna y el dominio es acotado (un producto, un servicio). 2. Procesamiento de documentos no estructurados Extraer información de facturas, contratos, emails, formularios escaneados. Reemplaza horas de transcripción manual. Funciona bien cuando los documentos son variados pero el output esperado es estructurado (campos definidos). 3. Investigación y síntesis Buscar información en múltiples fuentes (BD interna, web, documentos), sintetizarla y producir un reporte. Útil para áreas de inteligencia comercial, análisis de competencia, due diligence. 4. Generación y revisión de contenido Borradores de propuestas comerciales, primer pase de revisión de pliegos, redacción de comunicaciones internas. Siempre con humano revisor antes de publicar. 5. Operaciones internas con sistemas múltiples Onboarding de empleados, generación de reportes que requieren consultar varios sistemas, conciliaciones simples. Estos casos eran de RPA hace dos años; con agentes son más resilientes a cambios en los sistemas. Casos donde NO conviene usar agentes (todavía) Decisiones financieras o regulatorias críticas sin humano en el loop . Aprobaciones de crédito, decisiones legales, diagnósticos médicos. La regulación no acompaña y el riesgo es alto. Procesos donde los errores son irreversibles . Pagos, transferencias, eliminación de datos. Si querés agentes acá, deben ejecutar solo después de confirmación humana. Tareas con volumen muy alto y costo unitario bajo . Procesar 10 millones de transacciones por día con un agente que cuesta USD 0.05 cada una es una mala decisión económica. RPA o código tradicional acá. Áreas con datos extremadamente sensibles sin control de acceso fino . Los modelos pueden tener "fugas" no intencionadas. Sin arquitectura de permisos clara, mejor no. Cómo arrancar sin tirar plata Paso 1: Identificar UN caso, no diez Es la trampa más común: querer que el primer piloto valide "la estrategia de IA" de toda la empresa. Mal. Elegí un proceso , idealmente uno que ocurra muchas veces por semana, con métricas claras (tiempo, costo, error rate) y donde el resultado se pueda medir en 60-90 días. Paso 2: Definir métrica de éxito ANTES de empezar "Reducir el tiempo medio de respuesta de consultas tipo X de 4 horas a 1 hora, manteniendo o mejorando la satisfacción del cliente". Esto se debe poder medir con datos que ya existen. Si no podés medirlo, mejor elegí otro caso. Paso 3: Construir lo mínimo viable Un agente que resuelve el 30% de los casos y escala el resto a humano YA es valor. No esperes al 95%. La iteración es donde mejora. Paso 4: Medir, iterar, escalar (o matar) A los 60-90 días tenés que tener una decisión: el caso funciona y se escala, o no funciona y se cierra. Pilotos eternos sin decisión son la peor inversión. Stack típico de un agente en producción (2026) Sin entrar en detalles técnicos profundos, las piezas típicas son: Modelo : Claude (Anthropic), GPT (OpenAI), Gemini (Google) o modelos locales (Llama, Mistral) si hay restricciones de datos. Conexión a herramientas : cada vez más vía Model Context Protocol (MCP) , el estándar abierto que reemplaza los conectores custom. Orquestación : LangGraph, CrewAI, n8n, o código custom según complejidad. Observabilidad : Langfuse, Helicone, o stack propio. Sin esto no se puede operar en producción. Evaluación automática : tests que corren periódicamente para detectar degradación. Crítico cuando se cambia de modelo o se actualiza el prompt. ¿Cuánto cuesta? El costo se divide en tres: Desarrollo inicial : USD 15.000 - 60.000 para un piloto serio (3-4 meses), dependiendo de la complejidad y la integración con sistemas existentes. Operación : API costs (Anthropic, OpenAI), infra cloud, observabilidad. Para un agente con uso mediano, USD 200 - 2.000 mensuales. Mantenimiento : 10-20% del desarrollo inicial por año. Modelos cambian, prompts se ajustan, integraciones se rompen. Cuidado con propuestas que prometen "agente de IA por USD 5.000 todo incluido". O es un chatbot disfrazado, o el costo real va a aparecer en operación. Preguntas frecuentes ¿Cuánto tarda en mostrar valor un agente de IA? Si el caso está bien definido y los datos están accesibles: 6-12 semanas para ver primeros resultados. 3-6 meses para tener métricas sólidas. Si después de 6 meses no hay valor medible, el problema no es el modelo — es el caso elegido o la implementación. ¿Puedo entrenar un modelo con mis datos privados? En la mayoría de los casos no hace falta. Las técnicas modernas (RAG, MCP, in-context learning) permiten que el modelo use tus datos sin entrenarlo. Entrenar (fine-tuning o RLHF) tiene sentido en casos muy específicos — y siempre después de agotar los enfoques más simples. ¿Necesito un equipo grande para arrancar? No. Un piloto serio se puede hacer con 1-2 ingenieros y un product owner del lado del negocio (clave). Lo que sí necesitás: sponsor con poder, alcance acotado y datos accesibles. ¿Qué pasa con la regulación? En Uruguay, la Estrategia Nacional de IA 2024-2030 y la Ley 20.212 marcan el tono. Para empresas privadas, la regulación específica todavía está en formación, pero conviene operar como si ya existiera: trazabilidad, explicabilidad, manejo claro de datos personales, opt-in informado. La UE con el AI Act ya define el horizonte y LATAM va a converger. ¿Querés evaluar si un agente de IA tiene sentido para tu empresa? Ofrezco diagnósticos cortos para identificar el primer caso de uso. Ver servicios · Conversemos . ================================================================================ PAGE: Cómo elegir un consultor de IA: 7 criterios y 5 red flags SOURCE: source/blog/como-elegir-consultor-ia.html.erb ================================================================================ 4 de abril de 2026 · 8 min de lectura Cómo elegir un consultor de IA: 7 criterios y 5 red flags Hoy en Uruguay y LATAM hay una avalancha de oferta: consultoras tradicionales con "práctica de IA", agencias nuevas, freelances, partners grandes (EY, Deloitte). Esta es la guía que le doy a un director cuando me pregunta cómo separar a los buenos de los charlatanes — incluso cuando está evaluando si trabajar conmigo o con otro. Primero: ¿qué tipo de proveedor estás buscando? No todos los proveedores hacen lo mismo. Pedir el mismo a todos es perder tiempo. Consultor independiente o boutique chica Cuándo conviene : diagnóstico, validación de hipótesis, piloto rápido (2-4 meses), arquitectura inicial. Cuando necesitás criterio senior aplicado, sin pasar por capas de account management. Cuándo no conviene : implementaciones grandes con compromiso de mantenimiento por 3+ años, proyectos con 10+ personas en paralelo, situaciones donde necesitás SLA 24x7. Agencia mediana especializada en IA Cuándo conviene : cuando ya validaste el caso y necesitás un equipo de 3-8 personas para construirlo en 4-9 meses. Tienen procesos, métodos y experiencia replicada en múltiples clientes. Cuándo no conviene : para diagnóstico inicial — vas a pagar por la estructura sin necesitarla. Empresa grande de software / Big 4 Cuándo conviene : implementaciones a nivel corporativo (no por área), múltiples geografías, necesidad de respaldo de marca (auditorías, requerimientos de board). Cuándo no conviene : cuando necesitás velocidad. Sus tiempos son largos, sus precios son altos y normalmente los seniors solo aparecen en la venta — la implementación la hacen juniors. Freelance individual Cuándo conviene : tareas muy puntuales (fine-tuning, prompt engineering específico, integración chica). Cuando ya tenés tu equipo armado y necesitás complementar capacidad. Cuándo no conviene : para liderar el primer caso de IA de tu empresa. Necesitás criterio de negocio, no solo skill técnico. 7 criterios para evaluar al proveedor 1. Casos verificables, no presentaciones Pedí 2-3 referencias específicas: nombre de cliente, qué se hizo, qué métrica mejoró, contacto verificable. Si solo te muestran logos sin contexto, malo. Si dicen "no podemos compartir por NDA" en TODOS los casos, peor — alguno tiene que ser público. 2. Que vos hables con quien va a hacer el trabajo Si en la venta hablás con un partner senior y en el kickoff aparecen tres juniors que nunca viste, hay un problema. Insistí en conocer al equipo real desde la propuesta. 3. Que defina la métrica de éxito ANTES de empezar Un buen proveedor te ayuda a articular: "este piloto funciona si reducimos el tiempo medio de X de 4 horas a 1 hora, manteniendo CSAT por encima de 4.2". Si la propuesta solo habla de "implementar la solución" sin métrica, mala señal. 4. Propiedad clara del código y los modelos ¿De quién es el código que se desarrolla? ¿Y los prompts? ¿Y los datos? Tiene que estar escrito en el contrato. Por defecto, debería ser tuyo (con licencia para que el proveedor lo use en otros clientes en partes genéricas, está bien). Si el proveedor se queda con todo, vas a depender de él para siempre. 5. Plan de traspaso documentado Al final del piloto, ¿podés operar el sistema sin el proveedor? Esto debería estar en la propuesta inicial: documentación, dashboards de monitoreo, capacitación a tu equipo. Si el proveedor se hace imprescindible, no es buen partner — es proveedor con candado. 6. Honestidad sobre lo que NO sabe o NO va a hacer Un buen proveedor te dice "esto que pedís no es la mejor manera de resolverlo, sería mejor X" o "este caso no tiene buen ROI con IA, te recomiendo seguir con el proceso actual". Si todo lo que pedís recibe un "sí, dale, lo hacemos", desconfiá. 7. Track record en producción, no solo en demos Construir un demo es fácil. Operar IA en producción durante meses es completamente otra cosa: monitoreo, manejo de costos, evaluación automática, manejo de errores. Pedí ejemplos de sistemas que el proveedor está operando hoy, no solo proyectos terminados. 5 red flags que merecen un descarte directo 1. "Te lo entrego en 2 semanas todo cerrado" Un piloto serio tarda 2-4 meses. Quien promete 2 semanas está vendiendo un demo o un wrapper de ChatGPT. No es lo que necesitás. 2. Propuestas sin precios claros "Después definimos el alcance y el precio" es la receta perfecta para sorpresas. Una propuesta seria tiene precios para fases definidas, con criterios claros de qué entra y qué no. 3. Buzzwords sin sustancia Si la propuesta dice "transformación digital con IA cognitiva de última generación" y no podés explicar a tu CFO en 30 segundos qué se va a hacer, mal. Pedí lenguaje claro. 4. Equipo de venta separado del equipo técnico, sin overlap Si en las primeras 3 reuniones nunca apareció alguien técnico que entendiera tu negocio, es señal de que tu caso lo va a llevar adelante alguien que recién se va a enterar de los detalles después de firmar. 5. "Trabajamos con todos los grandes pero no podemos contártelo" NDAs existen, pero alguien tiene que ser referenciable. Si en 100% de los casos la respuesta es "no podemos contar", probablemente no haya tantos casos como dicen. Preguntas que SÍ hay que hacer en la primera reunión "¿Cuál es el primer entregable concreto y cuándo lo voy a tener?" Respuesta esperada: algo tangible en menos de 30 días. "¿Quién va a hacer el trabajo? ¿Los puedo conocer antes de firmar?" Respuesta esperada: sí, sin problema. "¿Cuál es la métrica de éxito y cómo la vamos a medir?" Respuesta esperada: una métrica numérica, con baseline actual y target. "¿De quién es el código y los datos?" Respuesta esperada: tuyo, con licencia para el proveedor en partes genéricas. "¿Qué pasa si no funciona?" Respuesta esperada: criterios claros para matar el proyecto sin penalty, y recomendación de qué hacer. "¿Qué tecnologías usan y por qué?" Respuesta esperada: nombres concretos (Claude, GPT, MCP, etc.) con razones del caso, no marketing genérico. "¿Cómo van a manejar la información sensible?" Respuesta esperada: arquitectura de datos clara, manejo de PII, logging de accesos. Cómo estructurar el primer engagement Recomendación honesta: arrancá con un diagnóstico corto y barato (USD 3.000 - 8.000, 1-2 semanas) que termine con un caso elegido y un plan de piloto. Esto te permite: Probar cómo trabaja el proveedor sin compromiso grande. Tener un entregable propio independientemente de lo que pase después. Validar que el proveedor entiende tu negocio antes de pasar a un proyecto grande. Si el diagnóstico está bien hecho, vas a saber si querés seguir con ese mismo proveedor para el piloto o no. Si la respuesta es "no", igual te quedás con un mapa de oportunidades útil para llamar a otro proveedor. Preguntas frecuentes ¿Cuánto debería pagar por una consultoría de IA en Uruguay? Diagnóstico inicial: USD 3.000 - 8.000. Piloto del primer caso: USD 15.000 - 60.000 según complejidad. Tarifas por hora de consultor senior IA en LATAM: USD 80 - 200/h. Por encima o por debajo de eso, pedí justificación. ¿Conviene un consultor uruguayo o uno de afuera? Para casos que requieren conocimiento del contexto local (sector público uruguayo, regulación BCU, idioma rioplatense en interfaces), conviene local. Para casos puramente técnicos sin componente cultural, da igual — pero la diferencia horaria y cultural pesa más de lo que parece en proyectos largos. ¿Cómo evalúo si el consultor realmente sabe de IA? Tres preguntas simples sirven mucho: (1) "Contame un caso donde lo que probaste no funcionó y por qué" — los que solo cuentan éxitos no han hecho mucho. (2) "¿Qué diferencia hay entre RAG y fine-tuning, y cuándo usarías cada uno?" — respuesta clara en 2 minutos. (3) "Mostrame algo que hayas escrito o construido público" — repos, posts técnicos, charlas grabadas. ¿Es mejor un consultor solo o un equipo? Para diagnóstico y piloto chico: un consultor senior alcanza. Para piloto mediano (4-6 meses): consultor + 1-2 ingenieros. Para implementación grande: equipo de 4+ personas. Pedir más gente de la necesaria infla costos sin agregar valor; pedir menos termina en demoras. ¿Cómo me protejo de quedar atado al proveedor? Cuatro cláusulas en el contrato: (1) el código y los modelos son tuyos, (2) hay traspaso documentado al final del piloto, (3) capacitación incluida para tu equipo, (4) derecho a auditar el sistema y a pedir el código fuente cuando quieras. ¿Estás evaluando proveedores de IA? Si querés un diagnóstico independiente antes de elegir, conversemos. Mirá mi trayectoria · Agendar llamada . ================================================================================ PAGE: IA en sector público uruguayo: estado, oportunidades y dónde mirar primero SOURCE: source/blog/ia-en-sector-publico-uruguayo.html.erb ================================================================================ 25 de abril de 2026 · 10 min de lectura IA en sector público uruguayo: estado, oportunidades y dónde mirar primero Uruguay tiene Estrategia Nacional de IA, sandboxes regulatorios, una agencia (AGESIC) que coordina, y más de 2.000 trámites en línea. Pero la mayoría de los organismos no sabe por dónde empezar a aplicar IA. Este es el mapa que yo usaría si estuviera del lado del Estado en 2026. Lo que pasó entre 2024 y 2026 En noviembre de 2023 se aprobó la Ley 20.212 , que creó el Comité Estratégico del Sector Público para IA y Datos. Un año después, en noviembre de 2024, ese comité aprobó la Estrategia Nacional de Inteligencia Artificial 2024-2030 , después de un proceso participativo con 300+ personas, 40 instituciones estatales y 45 organizaciones del sector privado. En 2025 entraron en vigor los sandboxes regulatorios de IA y datos , presididos por AGESIC. Son el espacio donde un organismo o empresa puede probar una solución de IA bajo supervisión, sin esperar a que exista regulación específica. Es la antesala del marco que va a venir. En paralelo, AGESIC firmó alianzas técnicas (Red Hat, Microsoft, BID con fAIr LAC), ANTEL anunció compras de infraestructura GPU, y empezaron a aparecer las primeras implementaciones reales: digesto municipal de la Intendencia de Montevideo (con Quanam y Microsoft), proyectos en BPS y MSP, capacitaciones masivas a funcionarios. El estado real, sin marketing La narrativa oficial es optimista. La realidad operativa es más matizada: Madurez heterogénea : AGESIC y los grandes organismos (BPS, DGI, ANTEL, BROU) tienen equipos técnicos y proveedores grandes. Las intendencias del interior y muchos ministerios están todavía en fase de "qué es esto". Compras lentas : los Convenios Marco UACM (1/2021 desarrollo, 3/2024 calidad) ayudan, pero un organismo medio que quiere un piloto de IA tarda meses en concretarlo. Talento escaso : la demanda de roles de IA en Uruguay creció 500% a inicios de 2026; los buenos perfiles están en empresas privadas o se van a Madrid/EE.UU. Cultura de evaluación : muchas iniciativas no tienen métricas claras de éxito antes de empezar. Esto va a doler en 2027. Dónde sí hay oportunidades concretas (orden de impacto) 1. Asistentes para consultas ciudadanas sobre trámites El portal gub.uy/tramites tiene más de 3.000 trámites documentados. Las preguntas que llegan a callcenters y mesas de entrada son repetitivas y tienen respuesta exacta en el portal. Un agente de IA conectado al portal (vía MCP, ver mi artículo sobre el MCP de tramites.gub.uy ) responde en segundos lo que un funcionario tarda 5-10 minutos. Impacto: reducción de carga operativa + mejor experiencia ciudadana. 2. Asistentes internos para funcionarios Un organismo medio tiene cientos de procedimientos internos, normativa, convenios marco, jurisprudencia. Un asistente que un funcionario pueda consultar en lenguaje natural — "¿cuál es el plazo para responder este recurso administrativo?" — ahorra horas por semana por persona. La pieza técnica clave acá es indexar bien la documentación interna y manejar permisos. 3. Análisis de pliegos y contratación pública ARCE ya anunció que va a usar IA para asistir en la redacción de pliegos. Pero hay un problema gemelo: los proveedores también necesitan IA para responder pliegos, y los compradores para evaluar ofertas. Es un mercado en formación con espacio para herramientas específicas (no Microsoft 365 Copilot genérico). 4. Digestos y consolidación normativa El proyecto que Quanam hizo para la Intendencia de Montevideo (digestar 4.000 artículos del marco municipal) se puede replicar en cada intendencia, en cada ministerio, en cada organismo grande. Es un caso muy bien delimitado, con métricas claras y bajo riesgo regulatorio. 5. Auditoría y compliance asistidos Para organismos sujetos a auditorías recurrentes (TCR, Auditoría Interna de la Nación, controles BCU para públicos financieros), un sistema que pre-revisa documentación contra checklists conocidos baja muchísimo el costo de auditoría. Es la antesala del uso de IA en Tribunal de Cuentas. Errores que vale la pena evitar Cuatro patrones que se ven seguido en organismos que arrancan con IA: Empezar por el caso más sexy . "Un asistente que escriba políticas públicas". Mal. Empezar por el caso más aburrido y delimitado: clasificar tickets, responder FAQs, completar formularios. Ese es el que valida la cultura interna. Comprar plataforma antes de validar caso de uso . Una licencia de Copilot Enterprise no es una estrategia de IA. Primero el caso, después la herramienta. Olvidarse de la auditabilidad . En sector público, una decisión asistida por IA tiene que poder explicarse y trazarse. Si el sistema no logra eso, no entra a producción. Subestimar la gestión del cambio . La barrera no es técnica, es cultural. Si los funcionarios sienten que el sistema viene a reemplazarlos en vez de a ayudarlos, el piloto muere antes de empezar. Qué necesita un organismo antes de arrancar Tres prerrequisitos mínimos que ningún proveedor cuenta porque conviene venderte el piloto sin tenerlos: Un sponsor con poder real . Idealmente del comité de dirección, no del área de TI. Sin esto, el piloto se queda en POC. Una métrica de éxito definida antes de empezar . "Reducir el tiempo medio de respuesta de consultas X de 4 horas a 30 minutos". Sin esto, no hay forma de saber si funcionó. Acceso a los datos correctos . La mayor parte de los pilotos de IA en Estado mueren por falta de acceso a la base de datos correcta, no por la IA en sí. Negociar el acceso desde día uno. Cómo entro yo a esta conversación Trabajé cuatro años en AGESIC entre 2015 y 2022. Lideré la unificación de más de 70 portales gub.uy. Implementé la norma UNIT 1215 de Accesibilidad Web en tramites.gub.uy en 2015 . Construí los sistemas de Certificados de Vacunación durante COVID. Hoy aplico todo eso a la nueva ola de IA aplicada, sumando experiencia en Rappi, Tiendamia y Ueno Bank en sistemas críticos privados. No vengo a venderte la transformación digital con IA. Vengo a trabajar contigo en un caso concreto, validarlo, medirlo, y escalarlo si funciona. Si tu organismo está pensando en algo, conversemos sin compromiso. Preguntas frecuentes ¿La Estrategia Nacional de IA 2024-2030 es obligatoria para organismos? No es ley imperativa, pero define lineamientos que cualquier proyecto de IA en sector público va a ser comparado contra. Más importante: define los principios éticos (transparencia, explicabilidad, no discriminación) que sí terminan siendo evaluados por Tribunal de Cuentas y por la sociedad civil. ¿Qué son los sandboxes regulatorios de IA? Son espacios de prueba controlados donde un organismo o empresa puede experimentar con una solución de IA durante un tiempo definido, bajo supervisión de AGESIC y un comité técnico. Son la herramienta que permite probar antes de regular, sin esperar a que exista marco específico. ¿Qué presupuesto necesita un piloto serio de IA en sector público? Depende del caso, pero un piloto bien delimitado (3-4 meses, alcance acotado, métrica clara) está en el orden de USD 30.000 a USD 80.000. Por debajo de eso, normalmente es POC sin valor real. Por encima, hay que justificar mucho. ¿Conviene contratar a una empresa grande o a un consultor independiente? Para implementaciones grandes con compromiso de mantenimiento por años: empresa grande con estructura. Para diagnóstico, validación de hipótesis y pilotos rápidos: consultor independiente o boutique chica, mucho más ágil. Mi recomendación honesta: usá ambos, en distintos momentos del ciclo. ¿Tu organismo está evaluando IA? Ofrezco diagnósticos de oportunidades y desarrollo de pilotos. Ver servicios · Conversemos sin compromiso . ================================================================================ PAGE: IA para empresas en Uruguay: cómo arrancar sin tirar plata SOURCE: source/blog/ia-para-empresas-en-uruguay.html.erb ================================================================================ 11 de abril de 2026 · 9 min de lectura IA para empresas en Uruguay: cómo arrancar sin tirar plata La demanda de talento IA en Uruguay creció 500% a inicios de 2026 y el 43% de las empresas planea contratar roles de IA este año. Pero la mayoría no sabe por dónde empezar y termina pagando POCs eternos sin valor. Esta es la guía que daría a un Director que me llama por primera vez. El estado del mercado en Uruguay Tres cosas pasan al mismo tiempo: (1) los modelos de lenguaje (Claude, GPT, Gemini) son lo suficientemente buenos como para resolver problemas reales de negocio, (2) los precios bajaron una vez al año durante los últimos tres años, y (3) hay un ecosistema de proveedores uruguayos compitiendo (Tryolabs, Quanam, Conecta361, Agentify, Agentico, Byte Intelligence, AI Tech, Vex AI, KuberaLabs, RMR, EY) más boutiques chicas y consultores independientes. La buena noticia: ya no hace falta ser Google para usar IA en producción. La mala: el ruido es enorme y separar a los buenos proveedores de los charlatanes requiere criterio que muchos comités de dirección todavía no tienen. Casos donde la IA mueve la aguja hoy en empresas medianas 1. Atención al cliente y soporte de primera línea Triaje automático de tickets, respuesta a preguntas frecuentes, generación de borradores de respuesta para que el agente humano solo edite. Funciona muy bien cuando hay buena documentación interna y el dominio es acotado. ROI típico : reducción de 30-50% del tiempo medio de respuesta, aumento de capacidad de atención sin sumar headcount. 2. Procesamiento de documentos no estructurados Facturas, contratos, formularios escaneados, emails comerciales, pedidos por WhatsApp. La IA extrae los campos relevantes con un nivel de error competitivo con humanos, a un costo marginal mucho menor. ROI típico : 70-90% de reducción de horas de transcripción manual. 3. Generación y revisión de contenido Borradores de propuestas comerciales, descripciones de producto para e-commerce, comunicaciones internas, primer pase de revisión de pliegos. Siempre con humano editor antes de publicar. ROI típico : 3-5x productividad del equipo de marketing/ventas/legal en tareas repetitivas. 4. Ventas: cualificación de leads y reactivación Análisis automático del CRM para detectar leads dormidos con alto potencial, generación de mensajes personalizados, cualificación inicial vía chat o WhatsApp Business. ROI típico : aumento de 20-40% en leads cualificados con el mismo equipo. 5. Operaciones internas: reportes y conciliaciones Generación de reportes que requieren consultar varios sistemas, conciliaciones contables simples, alertas inteligentes. Lo que antes hacía un analista junior, ahora se asiste con IA y el analista hace lo más complejo. ROI típico : liberación de 10-20 horas semanales en áreas administrativas medianas. El error #1 que vemos seguido: empezar por el caso más sexy Llega el director y pide "un asistente que entienda el negocio y responda cualquier consulta". Es la peor manera de arrancar. La IA en empresas se valida con casos delimitados, no con visiones globales. El primer caso debe ser: Repetitivo (ocurre muchas veces por semana, idealmente por día). Acotado (un proceso, un área, un tipo de input). Medible (se puede comparar antes/después con datos que ya existen). De bajo riesgo (si falla, no hay daño irreversible). Una vez validado el primer caso y demostrado que la organización puede operar con IA, escalás. Cuánto cuesta arrancar realmente Tres componentes: Diagnóstico inicial : USD 3.000 - 8.000 para un taller estructurado y un informe priorizado de oportunidades. Esto debería terminar con 1-2 casos elegidos para piloto. Piloto del primer caso : USD 15.000 - 60.000 dependiendo de complejidad y nivel de integración con sistemas existentes. Plazo: 2-4 meses. Operación mensual : USD 200 - 2.500 por mes según volumen, costos de API (Anthropic, OpenAI), infraestructura y monitoreo. Cuidado con dos extremos: por un lado, propuestas de "agente de IA por USD 5.000 todo incluido" — o es chatbot disfrazado, o el costo real va a aparecer en operación. Por otro lado, ofertas de "transformación con IA" de USD 200.000 sin un caso concreto a validar primero. Cómo evaluar si tu empresa está lista Hago esta lista en cada diagnóstico inicial. Si tu empresa puede marcar 4 de los 6 puntos, está lista para un piloto: Hay un sponsor con poder de decisión (idealmente del comité de dirección, no solo de TI). Existe un proceso identificado que se ejecuta muchas veces por semana y consume tiempo de personas calificadas. Los datos relevantes están accesibles (en BD, en archivos digitales, no en cabezas o en papeles). Hay tolerancia a iterar: el equipo entiende que el primer mes el piloto va a fallar en cosas y va a mejorar. El presupuesto para el piloto está aprobado o aprobable sin pedir tres niveles de autorización. Hay alguien del lado del negocio (no solo de IT) que va a ser product owner del piloto. Stack típico que se usa hoy en empresas medianas uruguayas Modelos : Claude (Anthropic) para casos donde importa razonamiento y manejo de texto largo. GPT (OpenAI) para volumen y costo. Gemini (Google) si ya hay ecosistema Google Workspace. Integraciones : cada vez más vía Model Context Protocol (MCP) que estandariza la conexión con sistemas internos. Orquestación : n8n y Make para casos simples, LangGraph o CrewAI o código custom para casos complejos. Observabilidad : Langfuse o Helicone para ver qué hace el sistema y por qué falló cuando falla. Infraestructura : AWS, GCP o Azure según preferencias del equipo. Para datos muy sensibles hay opciones on-premise (modelos abiertos como Llama, Mistral). Lo que NO hay que hacer Comprar plataforma antes de validar caso de uso. Una licencia anual de Copilot Enterprise no es una estrategia de IA. Confundir IA generativa con automatización tradicional. Si tu proceso es estable y las reglas son claras, RPA o código tradicional es más barato y más confiable. La IA agrega valor cuando hay variabilidad, ambigüedad o juicio. No medir. Pilotos sin métricas iniciales son la receta perfecta para "fue bueno pero no sabemos cuánto". Ignorar gestión del cambio. El equipo tiene que entender que la IA viene a ayudarlos, no a reemplazarlos. Sin esto, el sistema termina siendo saboteado o ignorado. Sobre-prometer plazos. Un piloto serio tarda 2-4 meses, no 2 semanas. Quien promete 2 semanas está vendiendo demo, no producción. Preguntas frecuentes ¿Mi empresa es muy chica para hacer IA? Probablemente no. Hoy hay casos de IA con valor en empresas de 10-30 empleados. La pregunta correcta no es el tamaño, es: ¿hay un proceso repetitivo que consume tiempo y donde la IA puede ayudar? Si sí, vale la pena evaluarlo. ¿Cuánto tarda en mostrar valor? Si el caso está bien elegido y los datos están accesibles: 6-12 semanas para los primeros resultados. 3-6 meses para tener métricas sólidas. Si después de 6 meses no hay valor medible, normalmente el problema no es la IA, es el caso o la implementación. ¿Necesito contratar gente nueva? Para arrancar, no. Un piloto se puede hacer con un proveedor externo. Para escalar, conviene tener al menos una persona interna que entienda lo que se hizo y pueda mantenerlo o evolucionarlo. Esa persona puede ser alguien que ya tenés (con upskilling) o un nuevo perfil. ¿Qué pasa con la privacidad de mis datos? Los proveedores enterprise (Anthropic, OpenAI Enterprise, Google Cloud) tienen políticas claras: no usan tus datos para entrenar sus modelos. Para datos extremadamente sensibles, hay opciones de modelos abiertos (Llama, Mistral) corriendo en infraestructura propia. Lo que sí o sí hay que tener: arquitectura de permisos clara, logging de qué datos pasan por dónde, y un acuerdo legal sólido con el proveedor. ¿Conviene hacer todo con un proveedor o usar varios? Para arrancar, un solo proveedor para no fragmentar el aprendizaje. Para escalar, conviene mezclar: el modelo de un proveedor, la infraestructura de otro, la consultoría especializada de un tercero. Atarse a un solo proveedor por años es riesgo innecesario. ¿Cómo elijo un consultor o agencia de IA? Tengo un artículo dedicado a eso: Cómo elegir un consultor de IA . Spoiler: pedí casos verificables, no PowerPoints; preguntá por el primer entregable y por la métrica de éxito; desconfiá de quien te promete todo cerrado en 2 semanas. ¿Querés evaluar el primer caso de IA para tu empresa? Ofrezco diagnósticos cortos (1-2 días) que terminan con un informe priorizado y un caso elegido para piloto. Ver servicio · Conversemos sin compromiso . ================================================================================ PAGE: Cómo construí un MCP para tramites.gub.uy SOURCE: source/blog/mcp-para-tramites-gub-uy.html.erb ================================================================================ 2 de mayo de 2026 · 9 min de lectura Cómo construí un MCP para tramites.gub.uy Hay una pregunta que aparece todo el tiempo cuando uno trabaja con modelos de lenguaje: ¿cómo hacemos para que respondan con información útil, verificable y actualizada, sin depender de lo que "recuerdan"? Para trámites del Estado uruguayo, esa pregunta es especialmente importante. Esta es la solución que armé. Un trámite puede cambiar de requisitos, costos, oficinas, canales de atención o enlaces oficiales. Si un asistente responde desde memoria, puede sonar convincente y estar mal. Para este tipo de casos, el camino razonable es conectar el modelo a una fuente de datos concreta . Con esa idea armé MCP Trámites GUB.UY , un servidor MCP open source para consultar trámites publicados en la guía oficial de trámites de Uruguay. El código está en GitHub: github.com/fabdelgado/mcp-tramites-gub-uy . Hay un detalle personal en este proyecto. En 2015 implementé la norma UNIT 1215 de Accesibilidad Web en el portal tramites.gub.uy desde AGESIC. Diez años después, este MCP permite a agentes de IA operar ese mismo portal. Mismo trámite, distinta capa. Qué es Es un servidor escrito en Go que descarga el dump XML mensual publicado por AGESIC en catalogodatos.gub.uy , lo importa a SQLite y expone herramientas MCP para que un LLM pueda buscar y consultar trámites usando datos reales. La fuente es el dataset abierto AGESIC — Guía de trámites . La API CKAN usada es: https://catalogodatos.gub.uy/api/3/action/package_show?id=agesic-guia-de-tramites Los datos son de AGESIC y están publicados bajo licencia Creative Commons Attribution 4.0 International ( CC BY 4.0 ). El código del proyecto está bajo licencia MIT . Por qué MCP Model Context Protocol permite exponer herramientas y recursos a clientes compatibles, como Claude Desktop, Claude Code u otros entornos que puedan hablar el protocolo. En lugar de pedirle al modelo que "se acuerde" cómo se renueva un pasaporte, el modelo puede llamar una tool: search_uruguay_government_procedures(query, organismo?, limit?) Y después pedir el detalle: get_uruguay_government_procedure(id) Cada respuesta incluye: url_oficial last_updated_at atribución a AGESIC licencia de los datos Eso permite que el asistente responda con más cuidado, cite el enlace oficial y advierta sobre la frescura de la información. Qué expone el servidor El MCP server corre sobre transporte HTTP Streamable en /mcp . Las tools disponibles son: search_uruguay_government_procedures(query, organismo?, limit?) get_uruguay_government_procedure(id) list_uruguay_government_organismos() find_uruguay_procedure_offices(procedure_id, departamento?) También expone un resource: tramite://{id} La idea es que el LLM pueda buscar, ampliar contexto y traer el trámite completo cuando lo necesite. Arquitectura El proyecto tiene una arquitectura simple: CKAN API → XML mensual → ingest streaming → SQLite → FTS5 / embeddings → MCP HTTP Stack principal: Go Gin para HTTP routing SQLite con modernc.org/sqlite FTS5 para búsqueda léxica OpenAI embeddings para búsqueda semántica mcp-go para el servidor MCP Docker Compose para deploy Volumen persistente para la base SQLite El ingest descarga el XML real, lo parsea en streaming con encoding/xml , calcula un content_hash por trámite y hace upsert solo cuando detecta cambios. Si un trámite cambia, se resetea su embedding para regenerarlo. Si un trámite desaparece del XML actual, se marca con soft delete . Búsqueda El proyecto implementa tres modos: FTS5 Búsqueda léxica con SQLite FTS5, tokenizer unicode61 remove_diacritics 2 . Vector search Embeddings en memoria con similitud coseno. Hybrid search Combinación de FTS + vector usando Reciprocal Rank Fusion . En el servidor MCP, la búsqueda usa FTS5 por defecto. Si la base tiene embeddings cargados y está configurada OPENAI_API_KEY , intenta búsqueda híbrida. Si no puede, cae a FTS5 y lo deja declarado en la respuesta. Docker y Dokploy El proyecto está pensado para correr en Docker de forma simple. El primer arranque puede cargar la base automáticamente: BOOTSTRAP_INGEST=true Si la tabla de trámites está vacía, el entrypoint corre: /app/ingest --if-empty Después levanta el server. En reinicios posteriores, si la base ya tiene trámites, saltea el ingest y arranca rápido. La base vive en un volumen persistente: /data/tramites.db Esto lo hace cómodo para Dokploy: deployás el compose, exponés el puerto, configurás el dominio HTTPS y el endpoint MCP queda disponible en: https://tu-dominio.com/mcp Claude Desktop Para usarlo como custom connector remoto en Claude Desktop o Claude.ai, el endpoint tiene que ser público y accesible por HTTPS. Ejemplo: https://tramites.example.com/mcp . En Claude Desktop / Claude.ai: Settings → Customize → Connectors → Add custom connector Y se agrega como connector web. Para desarrollo local con Claude Code: claude mcp add --transport http tramites-gub-uy http://localhost:8080/mcp Hardening mínimo Además del flujo principal, el servidor incluye: Rate limit en memoria de 60 requests/min por IP . Logs JSON estructurados. Logs específicos de búsquedas MCP con event=mcp_query . Healthcheck HTTP. Dockerfile multi-stage. GitHub Actions con go build , go test , go vet y staticcheck . Cron de ejemplo para refrescar datos el día 5 de cada mes. No es una plataforma enorme. Es una pieza chica, mantenible y desplegable. Ejemplo de uso Buscar trámites por pasaporte: curl -sS -X POST https://tramites.example.com/mcp \ -H 'Content-Type: application/json' \ -H 'Accept: application/json, text/event-stream' \ -d '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"search_uruguay_government_procedures","arguments":{"query":"pasaporte","limit":3}}}' Obtener un trámite por ID: curl -sS -X POST https://tramites.example.com/mcp \ -H 'Content-Type: application/json' \ -H 'Accept: application/json, text/event-stream' \ -d '{"jsonrpc":"2.0","id":2,"method":"tools/call","params":{"name":"get_uruguay_government_procedure","arguments":{"id":"606"}}}' Leerlo como resource MCP: tramite://606 Algunas decisiones Quise mantener el proyecto deliberadamente sobrio. SQLite alcanza perfectamente para este volumen de datos. FTS5 resuelve muy bien la búsqueda textual. Para búsqueda semántica, cargar los embeddings en memoria es más simple que meter una base vectorial adicional, y para unos miles de trámites funciona sin drama. También preferí que el contenedor arranque con una DB funcional en el primer deploy. En un proyecto como este, la experiencia de despliegue importa : si alguien lo corre en Dokploy, debería poder levantar el servicio y empezar a consultar datos sin tener que ejecutar cinco comandos manuales. Próximos pasos posibles Algunas mejoras naturales: Endpoint administrativo para recargar el índice vectorial después de un ingest. Métricas Prometheus. Autenticación opcional para deployments públicos. Panel web simple para explorar trámites. Caché de respuestas MCP frecuentes. Job mensual integrado en el propio contenedor. Pero la base ya está: datos abiertos, ingest reproducible, búsqueda, MCP y deploy. Preguntas frecuentes ¿Por qué construir un MCP para trámites en lugar de un chatbot? Un chatbot vive en un sitio específico y depende de su base de conocimiento. Un MCP es una capa de datos : cualquier cliente compatible (Claude Desktop, Claude Code, ChatGPT con conectores) puede usarlo sin reescribir nada. Y la fuente es oficial: el dataset abierto de AGESIC en catalogodatos.gub.uy. ¿Por qué Go en lugar de Python? Tres razones: deploy más simple (binario único, sin gestión de dependencias en producción), consumo de memoria bajo para el tamaño del proyecto, y modernc.org/sqlite permite usar SQLite sin CGO, lo que simplifica los builds Docker multi-arquitectura. ¿Es seguro que un agente de IA opere trámites del Estado? Esta primera versión es read-only : solo consulta información pública del dataset abierto de AGESIC. No inicia trámites ni transmite datos personales. Para versiones operativas con sistemas internos de organismos, aplica todo lo que sé de mis 4 años en AGESIC y mi Máster en Ciberseguridad en curso : autenticación fuerte, autorización granular, trazabilidad completa. ¿Mi organismo o empresa puede pedir un MCP a medida? Sí. La arquitectura del proyecto (Go + SQLite + FTS5 + MCP HTTP Streamable) es replicable para cualquier dataset interno o API existente. Hago esto como servicio: ver "Desarrollo de agentes y MCPs" . ¿Dónde está el código? En GitHub: github.com/fabdelgado/mcp-tramites-gub-uy . Si trabajás con MCP, datos abiertos o asistentes aplicados a servicios públicos, este tipo de integración es un buen patrón: menos magia, más fuentes verificables . ¿Tu organismo o empresa necesita integrar IA con sistemas existentes? Construyo MCPs y agentes a medida con la misma filosofía: chico, mantenible, desplegable, con fuentes verificables. Ver servicios · Conversemos un proyecto . Para más contexto: IA en sector público uruguayo: estado y oportunidades .