108 preguntas — con respuestas escritas para decirse en voz alta

Soy ingeniero en mantenimiento industrial de la Santa María. Empecé en planta, en CMPC. Entré como mantenedor y a los seis meses me ascendieron a supervisor, con seis personas a cargo.

Ahí me pasó algo que me marcó. Vi que la gente perdía doce minutos caminando cada vez que necesitaba un manual, con la máquina parada. En vez de reclamarlo, me puse a programar una app para resolverlo. Esa fue mi entrada al software.

Después hice la ingeniería completa, un diplomado en inteligencia artificial en la PUCV, y en 2025 fundé Sudamérica AI. Es una plataforma que atiende clientes por WhatsApp con IA. Hoy tiene más de 230 cuentas activas y la construí yo.

Eso es lo que traigo. Entiendo la planta por dentro y sé programar la solución.

💡 Para cargos de mantenimiento, este orden funciona tal cual. Para cargos de IA, parte por Sudamérica AI y deja CMPC al final.

Por dos cosas. La primera es que junta mis dos mundos. He trabajado en operaciones y he construido software, y este rol necesita las dos cosas.

La segunda es de escala. Solo, llegué hasta donde pude llegar. Con un equipo y con respaldo detrás, lo mismo que hice rinde mucho más.

⚠️ Antes de cada entrevista, agrega dos frases sobre algo específico de la empresa. Sin eso, esta respuesta sirve para cualquier cargo y se nota.

Para estudiar la ingeniería. Salí en febrero de 2022 y entré a clases en marzo.

Ya había llegado a supervisor siendo técnico, y sabía que sin el título de ingeniero mi techo estaba puesto. Preferí ir por él completo, sin trabajar en paralelo. Quedé en buenos términos con la planta.

No paré. En enero de 2025 fundé Sudamérica AI y he estado en eso desde entonces, a tiempo completo.

Contraté tres desarrolladores en Brasil, armamos la base del producto, y después seguí solo hasta lanzarlo. En paralelo terminé el diplomado de IA en la PUCV, en septiembre del año pasado.

Ha sido el período en que más he aprendido en mi vida, sin comparación.

Liderando proyectos de digitalización dentro de una empresa, no solo ejecutándolos. Idealmente en esta.

Mi patrón ha sido ese. En CMPC entré a ejecutar y en medio año estaba dirigiendo. Me interesa crecer así, ganándomelo con resultados.

Si el cargo es industrial: haber normalizado el área de iluminación en CMPC. Me la entregaron sin ningún registro. Salí a terreno y levanté unos 2.000 puntos repartidos en más de 340 tableros. Armé las rutas de mantenimiento y rehíce los diagramas. Cuando me fui, el área tenía estándar.

Si el cargo es tecnológico: haber lanzado Sudamérica AI. Partió como una idea y hoy la usan más de 230 cuentas en 102 rubros. El backend, el frontend, la infraestructura y el sistema de IA los escribí yo.

Te doy tres.

Entiendo la operación y también sé programar. No necesito que alguien me traduzca el problema ni que otro me construya la solución.

Termino lo que empiezo. No me quedo en el diagnóstico bonito.

Y mido. Cada proyecto que he hecho tiene un número atrás, sea horas ahorradas o detenciones evitadas.

Me cuesta soltar tareas. Como soy capaz de hacer casi todo, tiendo a hacerlo yo en vez de delegarlo, y eso me frena.

Lo he ido corrigiendo con método. En CMPC dejé de supervisar contratista por contratista y armé checklists con foto obligatoria, así el estándar no dependía de que yo estuviera parado ahí. Con el equipo de Brasil me obligué a escribir criterios de aceptación claros en vez de revisar cada línea.

Sigo siendo así, pero ya sé cómo compensarlo.

💡 Debilidad verdadera + prueba concreta de que la manejas. Nunca "soy muy perfeccionista": esa respuesta la escucharon cien veces hoy.

Porque este cruce es raro de encontrar. La mayoría viene del lado de operaciones o del lado del software, no de los dos.

Yo supervisé mantenimiento en una planta de celulosa. Y también diseñé y programé una plataforma con IA que hoy está en producción con cientos de cuentas.

En la práctica eso significa que entiendo lo que le duele al que está en terreno, y puedo construir lo que lo resuelve sin intermediarios.

[Esta se prepara antes. No se improvisa nunca.]

Estructura que funciona: primero, qué hacen y en qué mercado están. Segundo, algo reciente que hayan hecho, una noticia, un proyecto, una expansión. Tercero, la conexión contigo: "vi que están haciendo X, y justamente eso es lo que hice en Y".

⚠️ Diez minutos en su web y en su LinkedIn antes de cada entrevista. Es la pregunta más barata de preparar y la que más gente elimina.

Visto desde afuera parece un salto, pero es la misma línea.

Yo ya programaba estando en la planta. Hice la app de documentación técnica y automaticé la carga de datos a SAP siendo supervisor, no después. La tecnología siempre fue mi manera de resolver problemas de operación.

La ingeniería y el diplomado fueron ir a fondo en eso mismo. No me cambié de rubro, me especialicé.

Sí, sin problema. Tengo disponibilidad inmediata, auto propio y licencia clase B.

Ya trabajé en planta, con mantenciones generales incluidas, así que sé perfectamente cómo es el ritmo. Y estoy dispuesto a moverme a otra ciudad si el cargo lo requiere.

Veía el mantenimiento de alumbrado y climatización de toda la Planta Maule. Tenía seis personas a cargo y coordinaba también a las empresas contratistas.

El día a día era planificar rutas, priorizar órdenes de trabajo, revisar en terreno y responder por que quedara bien hecho. Además me metí por mi cuenta a digitalizar el área, porque la información estaba en papel y en la cabeza de la gente.

Recibí un área que llevaba años postergada. No había catastro. Nadie sabía con certeza cuántos puntos había ni dónde estaban.

Salí a levantarlo a terreno. Terminé mapeando unos 2.000 puntos en más de 340 tableros. Con eso armé las rutas de mantenimiento y rehíce los diagramas de máquinas, que estaban desactualizados.

El área pasó de no tener ni una lista a estar en estándar normativo, con rutas que cualquiera podía ejecutar.

💡 Este es tu mejor caso industrial. Practícalo hasta que salga sin pensar.

Atacando un problema que nadie miraba: el acceso a los manuales.

En las mantenciones generales, cada vez que un mantenedor necesitaba consultar documentación tenía que caminar hasta la oficina. Doce minutos ida y vuelta, con la máquina detenida. En celulosa cada minuto parado cuesta miles de dólares.

Hice una app web en AppSheet que funcionaba sin instalación y sin señal. Los manuales quedaron en el teléfono, en terreno. Esos doce minutos por consulta desaparecieron.

Porque en planta hay zonas sin señal, y justo ahí están las máquinas.

Una carpeta en la nube te falla exactamente cuando la necesitas. La app guardaba todo en el teléfono y sincronizaba sola cuando volvía la conexión. El mantenedor nunca quedaba colgado.

Lo otro que importó fue que no había que instalar nada. Si hubiera pedido instalar una app, la mitad no la usa.

La carga se hacía registro por registro, a mano. Horas de gente calificada picando datos.

Me metí a estudiar cómo estaban armadas las bases de SAP por dentro. Después estructuré la información con ese mismo formato, y eso permitió subirla de una sola vez.

Cada jefatura recuperó unas dos horas y media a la semana. Eran cinco jefaturas, así que fueron unas doce horas y media semanales en total, más doce planificadores que dejaron de esperar esa carga.

MTBF es el tiempo promedio entre fallas. Te dice qué tan confiable es el activo. MTTR es cuánto demoras en repararlo. Te dice qué tan rápido responde tu organización.

Sirven para saber dónde parar la mano. Si el MTBF está bajo, el problema es el equipo o la estrategia de mantenimiento. Si el MTTR está alto, el problema suele ser repuestos, documentación o competencias.

En CMPC toqué los dos sin llamarlos así. Cambiar las luminarias de zonas calientes subió el tiempo entre fallas. La app de manuales bajó el tiempo de reparación.

Correctivo es reparar cuando ya falló. Es el más caro si te detiene producción.

Preventivo es intervenir cada cierto tiempo, falle o no. Controlas el riesgo, pero a veces cambias cosas que estaban buenas.

Predictivo es intervenir según la condición real del equipo, medida con datos. Es el ideal cuando el monitoreo se paga solo.

Mi tesis de técnico iba justo por ahí. Era un dispositivo con Raspberry Pi para calibrar transmisores de consistencia sin tener que ir al equipo.

Las luminarias de las zonas calientes se quemaban antes de tiempo. Para cambiarlas había que programar detenciones de producción.

Revisé el historial y el patrón era claro: fallaban por temperatura. La luminaria estándar que estábamos comprando no estaba especificada para esas condiciones. Nadie lo había mirado porque siempre se había hecho así.

Propuse cambiar el estándar por luminarias importadas para alta temperatura. Costaban más por unidad, pero se dejaron de programar detenciones para cambiarlas. La inversión se recuperó rápido.

Con reglas claras, no estando encima de ellos.

Armé checklists digitales con el paso a paso, y dejé obligatoria la foto antes y después de cada intervención. Con eso yo sabía qué se hizo y cómo quedó, sin tener que ir a verificar cada trabajo.

Además se acabó la discusión típica de "yo lo dejé bien". La foto estaba ahí.

Primero seguridad de las personas. Eso no se discute.

Después criticidad del equipo: qué pasa con la producción si falla, y si hay respaldo o no.

Y tercero, comparar lo que cuesta la detención contra lo que cuesta postergar.

Pero el requisito antes de todo eso son datos confiables. En CMPC lo primero que tuve que hacer fue el catastro, porque sin él la priorización era pura intuición.

Lo usé como supervisor, del lado de la gestión: avisos, órdenes de trabajo y datos maestros.

Mi aporte distinto fue meterme en cómo estaba estructurada la información por debajo. Eso me permitió armar la carga masiva que liberó doce horas y media semanales entre cinco jefaturas.

No me vendo como consultor SAP, porque no lo soy. Sé usarlo bien y sé hacer que trabaje para el equipo.

Con lo estándar de planta, sin inventar nada. Permiso de trabajo, bloqueo, verificación de energía cero antes de tocar, y el EPP que corresponda. Los trabajos en altura con su protocolo aparte.

Como supervisor mi pega era que eso se cumpliera siempre, no cuando había alguien mirando. Por eso los checklists de contratistas traían las verificaciones de seguridad como pasos obligatorios, no como recomendación al final.

El primer mes, mirar y preguntar. Cómo están los activos críticos de verdad, qué tan confiable es la información en el sistema, y cómo se prioriza hoy.

El segundo mes, atacar lo que aparezca fácil y visible. Casi siempre está en los datos, que es donde se pierde plata sin que nadie lo note. Eso fue exactamente lo que me pasó en CMPC.

El tercero, armar el plan de mediano plazo y acordarlo con las jefaturas.

Lo que no voy a hacer es llegar con la receta puesta antes de conocer la planta.

Porque hice cosas que no me correspondían.

Entré como mantenedor a ejecutar órdenes, y en vez de quedarme ahí me puse a ordenar la información del área y a programar la app de documentación. Cuando se abrió el cargo, yo ya estaba resolviendo problemas de supervisor.

También jugó a favor que conocía la planta desde mi práctica del año anterior.

Cumplimiento del plan, backlog y disponibilidad de los sistemas a mi cargo.

Pero te voy a ser honesto con el punto de partida. Cuando recibí el área de iluminación no había registro confiable de nada. Y un KPI sobre datos malos es un número inventado.

Por eso mi primer trabajo fue construir la base: el catastro de los 2.000 puntos, las rutas y el sistema de registro. Recién ahí los indicadores empezaron a significar algo.

Es una plataforma para pymes que atiende clientes por WhatsApp con inteligencia artificial.

El negocio conecta su WhatsApp y la IA contesta sola las 24 horas. Toma reservas, recibe pedidos, arma cotizaciones y le entrega al dueño sus números de gestión.

Funciona para 102 rubros distintos y hoy tiene más de 230 cuentas activas. La fundé en enero de 2025.

Porque la lancé gratis, y eso fue a propósito.

Quería validar el producto con negocios reales antes de cobrar, y funcionó. Pero un producto gratuito no me paga el sueldo. Hoy necesito estabilidad, y quiero aportar en un equipo todo lo que aprendí construyéndola.

La plataforma no me consume el día. Está automatizada, con más de 750 pruebas y evaluación automática de la IA, justamente para que no dependa de que yo esté encima.

🚨 Esta pregunta llega sí o sí. Ensáyala en voz alta hasta que te salga tranquila, sin sonar a excusa. La idea de fondo: la startup es la prueba de lo que sabes hacer, no un plan de escape.

Entiendo la duda y prefiero responderla de frente.

La plataforma está armada para exigirme lo mínimo. No tengo inversionistas, ni metas de crecimiento comprometidas, ni clientes pagando que me obliguen a estar disponible.

Si algún día eso cambiara, se los diría con tiempo. La prueba de que juego limpio es que se las estoy contando ahora, en vez de esconderla del CV.

De tiempo no. El mantenimiento es poco y lo hago fuera del horario laboral.

De interés tampoco. Atiende pymes chicas por WhatsApp, restaurantes, peluquerías, ferreterías. [Verificar que no se cruce con el giro del empleador.]

Y si tienen política de exclusividad o de declaración de intereses, la firmo y la cumplo sin problema.

Sacándole toda la fricción a la entrada. La lancé gratis en toda Latinoamérica.

Y el canal ayudó mucho. Funciona sobre WhatsApp, que ya es donde las pymes de la región venden. No tenía que convencer a nadie de cambiar de herramienta.

El resto fue difusión directa y que se corriera la voz. Preferí validar uso real antes que facturar temprano, y eso me dio algo que no se compra: feedback de cientos de negocios en 102 rubros distintos.

Porque nadie va a descargar una app para hablar con la ferretería de la esquina.

En Latinoamérica el comercio chico ya vive en WhatsApp. Construir ahí me ahorró la batalla más cara de todas, que es convencer a la gente de instalar algo nuevo.

La parte web sí existe, pero es para el dueño del negocio. Ahí ve sus números, su catálogo y su configuración. El cliente final nunca sale de WhatsApp.

No, y lo digo sin adornarlo. Es gratuita por decisión mía.

Preferí aprender del uso real a escala antes que monetizar con veinte clientes. Sabía el costo de esa decisión cuando la tomé.

Lo que sí me dejó fue aprendizaje que no habría comprado de otra forma. Sé operar una plataforma multi-cliente en producción, sé controlar lo que cuesta la infraestructura y los modelos de IA, y sé lo que de verdad necesita una pyme.

Tres cosas.

Que el problema siempre es tuyo. Si los pagos fallan un domingo, no hay otro equipo al que escalarle.

A priorizar en serio. Cuando el tiempo y la plata son finitos, aprendes rápido a distinguir lo que mueve la aguja de lo que solo es entretenido de hacer.

Y que todo tiene precio. Cada decisión técnica me llegaba como boleta a fin de mes: servidores, tokens, horas. Eso te cambia la cabeza para siempre.

Eran tres, remotos, en otro país y en otro idioma. Estar encima no era opción.

Lo que funcionó fue escribir bien. Cada tarea salía con el objetivo y con criterios de aceptación explícitos. Cuando hay barrera de idioma, la ambigüedad se paga carísimo.

Después usaba la revisión de código para dos cosas: controlar calidad y enseñar. Y dejamos pocos puntos de sincronía, casi todo asíncrono.

Aprendí que a distancia no lideras por presencia. Lideras por claridad.

Por plata, básicamente. Sin ingresos, mantener tres sueldos no era sostenible.

El producto ya tenía su base construida, así que tomé el resto yo: backend, frontend, infraestructura e IA. Fue lento, pero llegué al lanzamiento.

Esa etapa es donde más crecí técnicamente. No había ni un pedazo del sistema del que pudiera desentenderme.

Construir mucho antes de mostrar nada.

Al principio me pasé semanas haciendo funcionalidades que yo estaba seguro de que eran necesarias. Cuando salió a la calle, varias casi no se usaron. Semanas perdidas.

Lo corregí cambiando el orden: sacar lo mínimo que resuelve el problema, ver qué usa la gente de verdad, y recién ahí profundizar. Suena obvio dicho así, pero me costó plata aprenderlo.

Con dos insumos. Lo que me dicen los usuarios, y lo que muestran los datos de uso. Los dos, porque la gente pide soluciones cuando en realidad te está contando un problema.

Contra eso comparo impacto y esfuerzo, y ahí decido.

Un ejemplo. Pasar de un rubro a 102 sonaba a proyecto gigante. Pero al analizarlo bien, resultó ser un cambio de datos y no de código. Ese análisis previo convirtió meses en semanas.

Buscando qué tienen en común un restaurante, una peluquería y una ferretería.

Al final todos hacen lo mismo con distinto nombre: agendan algo, venden algo, cotizan algo. Modelé eso como diez primitivas de negocio y 25 capacidades que se activan o no según el rubro.

Todo vive en una sola fuente de verdad, con tests que avisan si el código, los datos de prueba y la base se desalinean.

Hoy sumar un rubro nuevo es configurar datos. Ya no es programar.

💡 Guarda esta respuesta para cuando pregunten por diseño de sistemas o escalabilidad. Muestra cabeza de arquitecto, no de programador.

Porque el sistema está hecho para no necesitarme.

La infraestructura escala sola, son servicios que crecen y se apagan según la demanda. Hay más de 750 pruebas automáticas que me avisan si rompí algo. Y la IA tiene su propia evaluación automática antes de cada cambio.

Cuando el sistema no está seguro de una respuesta, se la pasa a una persona en vez de improvisar.

Así mi tiempo se va en mejorar el sistema, no en apagar incendios.

Siguen funcionando igual, porque la plataforma opera sola. Ese fue el diseño desde el principio.

Lo que cambia es que el desarrollo activo pasa a mantención puntual, en mi tiempo libre. No tengo contratos de servicio ni compromisos de disponibilidad firmados con nadie.

Son dos piezas.

La primera es un orquestador que arma el prompt de cada conversación. Le inyecta quién es el negocio, de qué rubro es, sus datos, y solo las secciones de instrucciones que le corresponden según lo que ese rubro hace.

La segunda es el motor, que no guarda estado. Corre un loop de tool-calling con 28 herramientas, filtradas según las capacidades del rubro. Un restaurante ve reservas y pedidos. Una ferretería ve cotizaciones e inventario.

El estado vive en PostgreSQL. En cada turno se reconstruye el contexto desde la base.

Porque en producción necesito ver qué pasó en cada paso.

Los frameworks de agentes agregan capas de abstracción, y cuando algo falla a las dos de la mañana esas capas se vuelven una caja negra. Además cambian de API cada pocos meses.

Un loop de tool-calling bien hecho son unos cientos de líneas que controlo entero. Escribí más código propio, sí. A cambio entiendo el sistema hasta el fondo, y eso se nota cuando hay que depurar.

Es darle al modelo la posibilidad de llamar funciones en vez de solo escribir texto.

Yo defino las herramientas con su nombre, su descripción y sus parámetros. El modelo decide cuál usar, mi código la ejecuta contra el sistema real, y le devuelve el resultado para que siga.

Un caso concreto. El cliente escribe "quiero reservar mañana a las ocho". El modelo llama a la herramienta de disponibilidad, recibe los horarios reales de la base de datos y confirma. Nunca se inventa un horario, porque no es él quien lo sabe.

Con tres barreras.

La primera y la más importante: los datos duros nunca salen del modelo. Precios, horarios y stock los trae una herramienta que consulta la base. El modelo no los recuerda, los pregunta.

La segunda es el umbral de confianza. Si el sistema no está seguro, deriva a una persona en vez de arriesgarse.

La tercera es la evaluación automática, que detecta si un cambio de prompt empezó a producir respuestas menos fieles antes de que llegue a producción.

Es usar un modelo para calificar las respuestas de otro modelo.

Armé un set de conversaciones de prueba que representan los casos típicos. El agente las responde y un modelo juez las califica con criterios definidos: si respetó los datos reales, si el tono es el correcto, si resolvió lo que le pedían.

Eso corre como gate obligatorio. Si un cambio de prompts baja el puntaje, no entra. Y la corrida tiene tope de costo, para que evaluar salga barato y lo pueda hacer siempre.

Porque lo mido, no porque lo suponga.

Cada cambio pasa por el mismo set de casos y el mismo juez. Si el puntaje baja del umbral, el cambio se queda afuera.

Es tratar los prompts igual que el código. Nadie sube código sin pasar los tests. En mi sistema nadie toca un prompt sin pasar la evaluación.

En producción, Gemini 2.5 Flash y GPT-4o. Los uso por una API compatible con OpenAI, así puedo cambiarlos sin reescribir el sistema. También he evaluado DeepSeek, que sale más barato.

Aparte, Whisper transcribe los audios que mandan los clientes y ElevenLabs genera las respuestas de voz.

El criterio no es qué modelo está de moda. Es costo, latencia y calidad medidos en mi caso real con el pipeline de evaluación. Si un modelo chico responde igual de bien y cuesta un tercio, gana el chico.

En producción no, y fue una decisión pensada.

Mis datos son estructurados. Catálogos, horarios, reservas, todo en PostgreSQL. Para eso, consultar la base con herramientas es más preciso y más fácil de depurar que una búsqueda semántica.

Conozco RAG y sé cuándo corresponde: cuando tienes mucho texto libre, documentación, conocimiento suelto. Si el problema lo pide, lo implemento. Pero no voy a poner un vector store donde una consulta SQL responde mejor.

🚨 Jamás digas que usas RAG en producción. No está en el producto y un entrevistador técnico puede seguir preguntando hasta descubrirlo. Esta respuesta honesta impresiona más que la mentira.

Las que me sobrevivieron en producción son cuatro.

Estructura clara, con secciones separadas: quién eres, qué datos tienes, qué reglas sigues, qué herramientas hay.

Decir qué hacer, no una lista de prohibiciones vagas.

Ejemplos concretos para los casos que se prestan a confusión.

Y componer el prompt por pedazos en vez de un texto gigante. Cada rubro recibe solo lo suyo, así que el prompt de una ferretería ni siquiera contiene las instrucciones de reservas.

Lo demás es medir. Cambiar prompts a puro instinto no es ingeniería.

El motor no guarda nada. Todo el estado vive en la base de datos.

En cada turno el orquestador reconstruye el contexto: el historial que importa, los datos del negocio y en qué va la operación en curso. Eso hace que el sistema aguante reinicios y que pueda correr en varias instancias a la vez.

Le sumé un detalle que resultó clave. Por WhatsApp la gente escribe en ráfagas de mensajes cortos. Agrupo esos mensajes antes de llamar al modelo, y con eso la respuesta sale más coherente y cuesta menos.

Primero midiendo, porque la lentitud casi nunca está donde uno cree.

Instrumenté todo el recorrido del mensaje y aparecieron tres culpables. Los servicios que arrancaban desde cero cuando llegaba una conversación. Esperas artificiales que se habían ido acumulando en la lógica. Y el tiempo de razonamiento del modelo.

Los arreglé uno por uno: dejé instancias siempre encendidas, saqué las esperas y elegí modelos rápidos para los turnos de conversación.

Como una variable más de ingeniería, igual que la latencia.

Uso el modelo que cada tarea necesita, no el más grande para todo. Agrupo los mensajes para llamar menos veces al modelo. Mando solo el contexto que importa, no el historial completo. Y las corridas de evaluación tienen tope de gasto.

Cuando operas algo gratuito, cada conversación te sale de tu bolsillo. Pocas cosas te enseñan eficiencia tan rápido.

Casi siempre parto con prompting y herramientas. Iteras en minutos y no necesitas datos de entrenamiento.

El fine-tuning lo justifico en dos casos. Cuando hay un formato o un estilo muy particular que el prompt no logra estabilizar. O cuando el volumen es tan grande que vale la pena entrenar un modelo chico para bajar el costo.

En mi plataforma no aplicaba. Con 102 rubros habría necesitado un modelo por rubro, imposible de mantener. Por eso el prompt se arma dinámicamente.

No escribo 102 prompts. Escribo pedazos.

Hay una base común con la identidad y las reglas. Después se agregan módulos según lo que el rubro hace: si toma reservas, entra el módulo de reservas; si cotiza, entra el de cotizaciones.

Lo que no aplica ni siquiera se carga. Eso evita que el agente de una ferretería empiece a hablar de menús, y de paso ahorra tokens.

La configuración de qué activa cada rubro está en un solo lugar, con tests que la vigilan.

Nivel diplomado, y prefiero decirlo así. En la PUCV trabajé clasificación de imágenes y los fundamentos de redes convolucionales, con proyectos en Python.

No lo presento como experiencia de producción, porque no lo es. Mi fuerte profesional son los sistemas con LLM.

Dicho eso, la base está y aprendo rápido. Todo el stack que uso hoy lo aprendí construyendo.

Lo vi en el diplomado. Regresión, clasificación, métricas de evaluación, scikit-learn, el ciclo de preparar datos, entrenar y validar.

Mi experiencia real en producción está en LLM, eso es claro. Pero hay algo del ML clásico que me quedó y lo uso todos los días: la desconfianza. Definir la métrica antes de optimizar, tener un set de prueba aparte, y no creerle al resultado bonito. De ahí viene toda mi disciplina de evaluación de agentes.

Por Evolution API, que expone WhatsApp con webhooks.

Mi servicio de canales recibe el evento, agrupa los mensajes que vienen en ráfaga y normaliza el contenido. Los audios pasan por Whisper para transcribirlos, y las imágenes también se procesan. Recién ahí se lo entrega al orquestador.

La respuesta sale por el mismo camino. Puede incluir nota de voz generada con ElevenLabs, y maneja el "escribiendo" para que la conversación se sienta normal.

Poniendo la barrera en la base de datos, no en la aplicación.

Uso Row-Level Security de PostgreSQL. Las políticas están definidas en la base, así que una consulta solo puede ver las filas de su cliente. Aunque yo cometa un error y olvide un filtro en el código, la base no entrega datos ajenos.

Encima de eso, el orquestador arma cada contexto solo con datos del negocio de esa conversación. Pero la garantía real está abajo.

Atrás hay seis microservicios en FastAPI, Python 3.12, todo asíncrono, corriendo en Google Cloud Run. La base es PostgreSQL, con los datos de cada cliente aislados por Row-Level Security.

El frontend es Next.js 15 con React 19 y TypeScript. Uso Mantine para los componentes, Zustand para el estado y React Query para los datos.

WhatsApp entra por Evolution API con webhooks. Los pagos van con Stripe y Mercado Pago.

Todo eso está cubierto por más de 750 tests, con 80% de cobertura mínima para poder desplegar.

Porque los dominios tienen ritmos distintos. El servicio que recibe los webhooks de WhatsApp aguanta una carga muy distinta a la del motor de IA o al del ERP. Separados, cada uno escala y se despliega por su cuenta.

Ahora, te doy la parte honesta. Para una persona sola, seis servicios son caros de operar. Si empezara hoy partiría con dos o tres y separaría cuando doliera.

La decisión no fue mala, pero fue temprana.

Es una función de PostgreSQL donde defines políticas de acceso a nivel de fila. Cada consulta solo ve las filas del cliente que corresponde a la sesión.

La uso porque me pone la seguridad una capa más abajo que mi código. Si algún día me equivoco y se me pasa un filtro en una consulta, la base igual no entrega los datos del otro cliente.

En una plataforma multi-cliente ese error es de los que te terminan el negocio. Prefiero que no dependa de mi memoria.

Tengo más de 750 pruebas automáticas y un mínimo de 80% de cobertura como requisito para desplegar. Uso pytest atrás, Vitest adelante y Playwright para los flujos completos.

Pero hay una capa extra que casi nadie tiene. En un producto con IA, los tests normales no detectan la regresión más peligrosa, que es que el agente empiece a contestar peor sin que nada se rompa. Para eso está la evaluación automática con modelo juez.

Nada llega a producción sin pasar las dos.

Primero los tests. Si están en rojo, no se despliega nada.

Después Cloud Build arma la imagen y la etiqueta con el hash del commit, así siempre sé exactamente qué código está corriendo en producción. Eso se despliega a Cloud Run.

Cloud Run guarda las revisiones anteriores, así que volver atrás es mandar el tráfico a la versión previa. Un comando.

Tener esa salida de emergencia es lo que me permite desplegar seguido sin miedo.

Lo uso todos los días. Cada microservicio va en su imagen, porque es lo que Cloud Run despliega.

Escribo los Dockerfiles cuidando el tamaño y el tiempo de build, porque eso impacta directo en cuánto demora un servicio en levantarse. Y uso contenedores para reproducir producción en mi máquina.

Lo que no hago es administrar Kubernetes. Cloud Run me resuelve la orquestación y no voy a decir que tengo experiencia que no tengo.

Porque mi sistema pasa casi todo el tiempo esperando. Espera al modelo de IA, espera a la base, espera webhooks de afuera.

Con async un mismo proceso atiende muchas conversaciones mientras cada una espera lo suyo. Sin async, cada conversación bloquearía un hilo y se me acabarían rápido.

Uso FastAPI con SQLAlchemy async de punta a punta.

Cuando el trabajo es de cálculo puro, async no sirve de nada. Ahí se escala con más procesos. Pero ese no es mi caso.

Next.js porque me daba rutas, renderizado y optimización resueltos, con TypeScript en todo el proyecto. No quería armar esa infraestructura a mano.

Mantine porque necesitaba que el dashboard se viera bien siendo yo solo. Tiene buenos componentes y un sistema de temas serio. Ahí construí el panel de indicadores: velocidad del pipeline, conversión, horas ahorradas y retorno de la IA.

Zustand porque Redux era demasiado para lo que necesitaba. Y React Query porque el caché, los reintentos y la sincronización con el servidor ya los resuelve él.

Con Stripe y Mercado Pago. El segundo es obligatorio si quieres cobrar en Latinoamérica.

El link de pago se genera y se manda dentro de la misma conversación de WhatsApp. El cliente no sale a otra parte, que es donde se pierden las ventas.

La confirmación vuelve por webhook y actualiza el pedido.

Lo complicado de pagos no es cobrar, es que los estados calcen. Por eso los webhooks son idempotentes y cada transacción queda trazada contra su pedido.

Dos cosas.

Menos servicios al principio. La separación por dominio estaba bien pensada, pero me adelanté y cargué con complejidad que podía haber postergado.

Y la evaluación de la IA desde el día uno. La monté cuando el producto ya estaba andando, y las semanas en que cambié prompts a ojo fueron las de mayor riesgo. No se notaba nada, y eso es justamente lo peligroso.

Lo que repetiría sin dudar: multi-cliente con RLS desde el inicio, y los tests. Esas dos me devolvieron cada hora invertida.

Yendo a terreno, no pidiendo el procedimiento.

Miro cómo se hace de verdad, que casi nunca es como está escrito. Cronometro, cuento cuántas veces al día pasa, y sobre todo busco qué le molesta a la gente.

Así encontré los doce minutos de caminata en CMPC. Nadie lo reportaba como problema porque ya era parte del paisaje.

Después priorizo por impacto y parto por algo chico que se note. Ese primer resultado es el que te compra permiso para lo grande.

Convirtiendo la métrica de operación en plata.

El caso de SAP: dos horas y media semanales por jefatura, cinco jefaturas, doce horas y media a la semana de gente calificada. Eso anualizado contra un desarrollo que costó casi nada.

El de las luminarias: cada detención programada que evitas vale lo que vale esa producción parada. Contra eso, comprar luminarias más caras se paga solo.

Lo que no puede faltar es medir el antes. Sin línea base no tienes ROI, tienes un cuento.

Tratando de que resistirse cueste más que adaptarse.

Mi app en CMPC no había que instalarla, funcionaba sin señal y te ahorraba una caminata de doce minutos. Nadie se resistió a eso.

Con los contratistas fue distinto, ahí sí hubo pelea. Los checklists los tomaron como desconfianza. Lo resolví sentándome con los capataces, ajustando el formato con lo que ellos decían, y mostrándoles que la foto también los protegía a ellos cuando alguien reclamaba injustamente.

Casi siempre la resistencia te está diciendo qué le falta a tu solución.

Impacto contra esfuerzo, con el impacto definido en la métrica del negocio y no en lo entretenido que sea.

En la plataforma, cada funcionalidad compite contra datos de uso real. En CMPC prioricé el catastro antes que cualquier mejora, porque sin datos confiables todo lo demás era construir sobre arena.

Y algo que aprendí a golpes: hay que ordenar las victorias. Un resultado visible temprano te financia políticamente los proyectos largos.

El proyecto de SAP tocaba cinco jefaturas y doce planificadores. Ninguno estaba obligado a usar lo que yo hiciera.

La jugada fue diseñar pensando en el que menos quería cambiar. Repliqué exactamente el formato que ellos ya conocían, así adoptarlo no significaba aprender nada nuevo. Bajé el costo de decir que sí.

Con los contratistas la palanca fue otra: estándar explícito y verificable.

Cada grupo se mueve por una razón distinta y hay que encontrarla.

Empiezo por el resultado y dejo la tecnología para el final, si es que alguien pregunta.

No digo "implementé un sistema multi-agente con tool-calling". Digo "el negocio atiende clientes las 24 horas sin contratar a nadie más, y estas son las horas que se ahorra".

Uso comparaciones del mundo del que me escucha. Y me guío por una regla: si no lo puedo explicar simple, es que no lo entiendo suficiente.

El dashboard que hice sigue esa lógica. El gerente ve conversión y horas ahorradas, no métricas de modelo.

Trabajo con entregas cortas y feedback real, que es el fondo del asunto. Sin ser fundamentalista de las ceremonias.

En la plataforma tengo backlog priorizado, ciclos cortos y despliegue continuo con gates automáticos. Con el equipo de Brasil eran objetivos por iteración y revisión asíncrona.

Conozco Scrum y Kanban, y me adapto a como trabaje el equipo. Lo que miro para saber si funciona es qué tan seguido entregamos algo útil, no cuántas reuniones tenemos.

Con el número que definimos antes de partir, medido antes y después.

Si digitalizo documentación, el tiempo por consulta. Pasó de doce minutos a cero. Si automatizo una carga, las horas manuales que se liberan.

Lo que no acepto como éxito es "se implementó el sistema". Que exista no significa que se use, y que se use no significa que la operación mejoró.

Por el proceso, nunca por la tecnología.

Buscaría algo repetitivo, de mucho volumen, con datos disponibles y donde un error se pueda atajar. Atención de consultas, clasificación de documentos, primeros borradores de algo.

Ahí montaría un piloto chico, con la métrica de éxito definida antes de partir y con una persona revisando lo que la IA hace.

Y la evaluación automática desde el primer día. El error clásico es lanzar el piloto sin ninguna forma de saber si está respondiendo bien. Es exactamente lo que hago en mi plataforma.

Sí, y creo que tengo las tres piezas que hacen falta.

Sé levantar el proceso del cliente en su terreno. Lo hice en planta y lo hago con las pymes que usan mi plataforma.

Sé armar el caso de negocio con números, que es lo que finalmente firma el gerente.

Y puedo mostrar algo funcionando, porque sé construir. Una demo que anda convence más que veinte láminas.

Además me manejo en los dos idiomas de la reunión, el del gerente de operaciones y el del equipo técnico que después implementa.

En CMPC introduje checklists con foto obligatoria para los contratistas, y les cayó pésimo. Lo tomaron como que yo desconfiaba de su trabajo. Hubo rechazo abierto.

Yo necesitaba la trazabilidad, pero no a costa de romper la relación con las cuadrillas.

Me junté con los capataces y los dejé hablar primero. Ajusté el formato con lo que me dijeron, sacando cosas que efectivamente estaban de más. Y les mostré el otro lado: cuando alguien reclamara que un trabajo quedó mal, la foto los defendía a ellos.

Terminaron usándolo como respaldo propio. Se acabaron las discusiones sobre trabajos terminados.

Los primeros meses de Sudamérica AI los gasté construyendo funcionalidades que yo daba por obvias.

Cuando salió a la calle, varias casi no se tocaron. Fueron semanas de trabajo tirado.

Podría decir que fue mala suerte, pero el error fue de método: estaba construyendo sobre mi opinión en vez de sobre evidencia.

Lo cambié. Ahora saco lo mínimo que resuelve el problema, miro qué usa la gente y recién entonces profundizo. Y eso está metido en cómo priorizo hoy, no es solo una lección bonita.

💡 Un fracaso de verdad, con la corrección concreta, vale oro. "No recuerdo ningún fracaso" es la peor respuesta posible.

Cuando terminó la primera etapa de la startup tenía que decidir si seguía pagando a los tres desarrolladores. No había ingresos y el producto estaba a medio camino.

No tenía cómo saber cuánto faltaba de verdad para validarlo.

Lo que hice fue separar lo reversible de lo irreversible. Quedarme sin plata era irreversible. Avanzar más lento no lo era. Así que asumí el desarrollo solo y corté todo lo que no fuera indispensable para lanzar.

El producto salió y llegó a las 230 cuentas. Esa forma de decidir me quedó: cuando no sé, protejo lo que no tiene vuelta atrás.

Las mantenciones generales en CMPC. Ventana fija de días, decenas de trabajos al mismo tiempo, contratistas de afuera, y cada hora de atraso en el arranque cuesta muchísimo.

Yo tenía que entregar mi área completa dentro de esa ventana.

La gané antes de que empezara. Dejé listos los materiales, los permisos, las rutas y el orden de los trabajos con anticipación. Durante la parada me quedé en terreno resolviendo los desvíos ahí mismo, en vez de mandar correos.

Entregamos dentro de la ventana. Aprendí que en una parada el que improvisa pierde.

Cuando me quedé solo en la startup, el frontend no era lo mío. Next.js, React, TypeScript, nada de eso lo dominaba.

No había alternativa. O lo aprendía o el producto no salía.

Lo aprendí construyendo sobre el producto real, no viendo cursos. Cada funcionalidad era la clase. Y me apoyé en los tests para poder avanzar rápido sin romper lo que ya funcionaba.

Hoy todo el frontend que está en producción, incluido el dashboard, es código mío. Así aprendo yo: proyecto real y presión real.

Con los tres desarrolladores en Brasil. Remotos, en otro idioma y con diferencia horaria. Microgestionar era imposible.

Necesitaba que avanzaran sin depender de mí para cada duda.

Delegué por resultado. Cada tarea salía explicando para qué servía y qué tenía que cumplir para darse por lista. El cómo lo dejaba abierto. La revisión de código era mi punto de control, y también donde les enseñaba.

Construyeron la base del producto sin que yo escribiera esas líneas. Delegar no me resultó repartir tareas, me resultó pasar contexto.

Usuarios de la plataforma me dijeron que la IA se sentía lenta y como robot. Yo estaba orgulloso de que respondía correcto.

Mi primer impulso fue defenderme con las métricas de calidad, que estaban buenas. Me aguanté.

En vez de eso instrumenté la latencia completa, y ahí estaba la razón. Esperas acumuladas y servicios que arrancaban desde cero. Ellos tenían razón y yo estaba mirando la métrica equivocada.

Rediseñé esa parte y las conversaciones quedaron mucho más fluidas. Ese feedback me costó orgullo y me ahorró meses.

Recién entrado a CMPC como mantenedor, vi que cada consulta de manual costaba doce minutos de caminata con la máquina parada.

No era mi tarea arreglarlo. Nadie lo había pedido, porque estaba asumido como parte del trabajo.

Me puse a hacer la app por mi cuenta, fuera del horario. Y no la propuse como idea en una reunión, la llevé andando para que la probaran.

Se adoptó en el área y ese tiempo muerto se acabó. Fue parte de por qué me ascendieron a supervisor a los seis meses.

Subí un cambio a producción que dejó al agente respondiendo peor en ciertos casos. Y lo peor: me di cuenta por los síntomas, no por mis controles.

Tenía que cortar el daño rápido y asegurarme de que no se repitiera.

Volví a la versión anterior de inmediato, que se hace en un comando porque los despliegues son reversibles. Después busqué la causa con calma. Y lo más importante, convertí ese caso exacto en un test permanente del pipeline de evaluación.

Ese tipo de falla ya no puede llegar a producción sin que salte la alarma. La primera vez es aprendizaje, la segunda sería negligencia.

Quise cambiar el estándar de luminarias en CMPC por unas importadas para alta temperatura. Costaban bastante más por unidad y la decisión no era mía.

Tenía que convencer a mi jefatura.

No fui a decir que a mí me parecía mejor. Llevé el historial de fallas, cuántas detenciones habíamos programado solo para cambiar luminarias, cuánto cuesta cada una de esas detenciones, y la comparación contra el costo del cambio.

Lo aprobaron y las detenciones por recambio se terminaron. Con una jefatura no ganas insistiendo, ganas cuando decir que no sale más caro que decir que sí.

Durante 2025 tuve tres cosas encima: desarrollar la plataforma solo, operar las cuentas que ya estaban andando, y el diplomado de la PUCV.

Ninguna se podía caer.

Lo resolví con sistemas más que con fuerza de voluntad. Automaticé todo lo repetitivo, tests, evaluación y despliegue, para que operar no me consumiera el día. Reservé bloques largos para desarrollar. Y busqué que el diplomado alimentara directamente el producto, con eso dos frentes pasaron a ser uno.

Salió el producto, las cuentas siguieron andando y me titulé en septiembre.

Me pasó con el equipo remoto. Llegaban entregas que no eran lo que yo había pedido.

Necesitaba corregir el rumbo sin ponerme encima de ellos.

Lo primero que hice fue preguntarme si el problema era la persona o mi instrucción. Varias veces era mi instrucción: en remoto y entre idiomas, lo ambiguo se interpreta como cada uno puede. Endurecí los criterios de aceptación y acorté los ciclos de revisión, para pillar los desvíos en días y no en semanas.

Cuando después de eso la brecha seguía, ahí sí conversación directa sobre el desempeño. Las entregas terminaron alineándose.

La práctica fue de septiembre a diciembre de 2019. Entré contratado como mantenedor en abril de 2020, recién titulado de técnico. En octubre de ese año me ascendieron a supervisor. Estuve en ese cargo hasta febrero de 2022, y en marzo entré a la ingeniería.

🚨 Memoriza esto hasta que salga sin pensarlo. Dudar de tus propias fechas es la señal más fuerte de que algo no cuadra. La línea es: Técnico 2018-2020, CMPC 2019-2022, Ingeniería 2022-2024, Sudamérica AI 2025 a hoy. No queda ningún hueco.

Se lo muestro cuando quiera. Puedo abrir el panel con las cuentas y su actividad, o la base de datos directamente.

La forma más rápida es que se cree una cuenta usted mismo en sudamerica.ai y lo pruebe. Está público.

⚠️ Antes de una entrevista técnica, confirma la cifra real contra producción. Y solo ofrece la demo en vivo si estás seguro de que va a funcionar en ese momento.

El registro del dominio sudamerica.ai y los repositorios originales en GitHub, con su historial de commits. Se los muestro si quiere.

Y la plataforma está funcionando en vivo, que es lo más difícil de fingir.

⚠️ Nota interna: el git local que tienes a mano parte en 2026 porque son snapshots truncados. Si alguien quiere ver código, muéstrale el dominio y los repos originales. No ofrezcas los snapshots como prueba de antigüedad.

Era el equipo del área que tenía a cargo como supervisor. Aparte coordinaba cuadrillas de empresas contratistas para trabajos especializados y para las mantenciones mayores.

Para esas cuadrillas fue que armé los checklists y el registro fotográfico. Respondía por las dos cosas: mi equipo directo y la calidad de lo que hacían los externos.

⚠️ Elige una sola versión de esto y úsala siempre igual. Esta respuesta calza con el CV, que dice "equipo a cargo: 6 personas".

Son dos años, pero mire lo que pasó adentro. Entré como mantenedor y en seis meses estaba supervisando a seis personas, coordinando contratistas y sacando proyectos de normalización completos.

Y no me quedé quieto después. Hice la ingeniería a tiempo completo, y desde entonces llevo un año y medio construyendo y operando una plataforma en producción, con responsabilidades que normalmente se reparten entre un equipo.

Si me miden por años corridos, me va a faltar. Si me miden por lo que he entregado, creo que la conversación cambia.

Es una duda razonable. Le doy dos respuestas.

Sí trabajé dentro de una empresa grande. En CMPC coordinaba jefaturas, planificadores y contratistas, con procesos y jerarquías. Sé moverme en una organización.

Y en software, aunque la empresa sea mía, trabajo como si tuviera equipo. Uso control de versiones, hacía revisión de código cuando lideraba a los desarrolladores de Brasil, tengo 750 tests como gate y despliegues reversibles.

Esas prácticas existen precisamente para trabajar con otros. Las apliqué incluso estando solo.

Sí, la uso mucho, y no lo escondo. Me manejo muy bien con Claude Code y me hace bastante más rápido.

Pero la IA te acelera lo que ya sabes decidir. La arquitectura la diseño yo, los cambios los reviso yo y el que responde si algo se cae soy yo.

Mire el sistema: aislamiento por Row-Level Security, pipeline de evaluación, 750 tests. Eso no lo sugiere un autocompletado, son decisiones de ingeniería.

Y cuando algo falla de madrugada en producción, no hay IA que lo arregle sola.

Porque llevo años haciendo tecnología, y tengo el producto funcionando para demostrarlo. El título de origen dice de dónde vengo, no hasta dónde llego.

Y le doy vuelta el argumento. Muchos perfiles de software nunca han pisado el proceso que están automatizando. Yo lo operé.

Para cualquier empresa que toque el mundo físico, industria, logística, retail, esa combinación es justamente la que falta.

El título sí, la experiencia no. Soy técnico universitario desde 2020 y ya había hecho dos años de planta antes de entrar a la ingeniería, incluyendo el cargo de supervisor.

O sea que la ingeniería la hice encima de experiencia real, no antes de tenerla.

Y desde que me titulé no he parado: fundé y lancé la plataforma, y saqué el diplomado de IA.

Sí, y no me complica. Ya trabajé así en CMPC, con mantenciones generales y jornadas largas incluidas.

Tengo disponibilidad inmediata, auto propio y licencia clase B, y puedo moverme de ciudad si hace falta.

Además me gusta el terreno. Mis mejores ideas salieron caminando la planta, no sentado en el escritorio.

Mi pretensión es de un millón doscientos cincuenta mil brutos.

Tengo flexibilidad según el alcance del cargo y el paquete completo. Me interesa más el proyecto y hacia dónde puedo crecer que apretar el primer sueldo.

Si el rango que manejan es otro, prefiero que me lo digan y lo conversamos con números.

💡 Si te presionan con "¿y si fuera menos?", responde: "escucho la propuesta completa y la evalúo". No te bajes tú solo en la primera conversación.

De inmediato. No tengo empleador actual ni aviso que dar.

La startup no requiere ninguna transición, porque funciona sola.

Sí, estoy buscando activamente y tengo otros procesos andando. Prefiero decirlo.

Este me interesa en particular por [razón específica del cargo]. Y si avanzamos, les aviso cómo vienen mis tiempos, para que el proceso no nos juegue en contra a ninguno de los dos.

💡 Tener procesos activos te sube el valor. Pero nunca inventes una oferta que no existe: si te piden detalles, se nota al segundo.

Tres cosas.

Un cargo donde no pueda mover ningún número. Necesito que mi trabajo se note en algo medible.

Un lugar donde los problemas se administren en vez de resolverse.

Y condiciones que no aguanten en el tiempo.

Fuera de eso soy bastante flexible. He trabajado en planta, remoto, solo y con equipo.

Sí, una sola cosa. Pueden probar mi trabajo hoy mismo.

La plataforma que construí está pública en sudamerica.ai. No es común que un candidato pueda decir "esto es lo que sé hacer, pruébelo usted".

Y que mi interés en este cargo es concreto, por [conectar con algo específico]. Gracias por el tiempo.

Siempre di que sí. No tener preguntas se lee como que no te importa el cargo.

Elige dos o tres de la lista de abajo, según cómo haya ido la conversación.