Riccardo Tagliavia Arquitecto de IA Aplicada

Lo difícil nunca
fue el modelo.

Lo difícil es encontrar el punto exacto del negocio donde la IA mueve dinero de verdad — y construir los sistemas que evitan que lo aprendido por tu equipo se vaya con las personas que lo aprendieron.

Con base en
Ciudad de Panamá
Trabaja en
Recuperación, sistemas de agentes, salvaguardas
Disponible para
Asesoría y proyectos de construcción

Qué hago

Dos problemas, una misma disciplina.

Ambos se reducen a la misma decisión: qué debe saber un sistema, y cuándo. Si eso queda bien resuelto, qué modelo uses pasa a ser casi un detalle de implementación.

Palanca

Convertir un dolor operativo en un flujo de ingresos

Empiezo por cómo gana dinero el negocio, no por una lista de capacidades de IA. Una vez que la restricción está clara, apunto recuperación, automatización y salvaguardas a ese único punto, en lugar de repartirlas por todo un roadmap.

Cómo funciona

Memoria

Que lo que aprende tu equipo se quede en la empresa

Los equipos que trabajan con IA entregan más rápido de lo que documentan. El código queda; el razonamiento detrás, no. Y se va cuando se va la gente. Es una pérdida lenta del activo que en realidad estás pagando.

Cómo funciona

02 / Palanca

Dónde la IA mueve dinero de verdad.

La mayoría de los programas de IA empiezan por la tecnología y después salen a buscar un caso de uso. Por eso suelen quedarse estancados después del piloto. Yo lo hago al revés: cuatro pasos, en este orden, porque cada uno acota el siguiente.

  1. 01

    Mapear cómo gana el negocio

    Por dónde entra el ingreso, por dónde sale el costo y en qué entregas el trabajo se queda esperando. Es un mapa del dinero, no una auditoría de tus herramientas.

  2. 02

    Encontrar el punto que vale la pena atacar

    El paso donde las demoras, los errores o el contexto olvidado se acumulan en silencio hasta convertirse en dinero real. Si no se puede enunciar en una frase con un número adentro, todavía no es el correcto.

  3. 03

    Construir el sistema a su alrededor

    Respuestas ancladas en tus propios datos en lugar de las suposiciones de un modelo genérico, conectadas a las herramientas que hacen el trabajo, y con límites claros sobre qué corre sin supervisión. El sistema es el producto; el modelo es intercambiable.

  4. 04

    Que mejore con su propia evidencia

    Registrar qué funcionó y devolvérselo al sistema, para que mejore de forma medible en lo único que paga. Sin este paso tienes una demo que envejece mal.

03 / Memoria

Tu equipo está entregando código que nadie termina de entender.

La IA hizo que escribir código fuera rápido y que entenderlo fuera opcional. El cambio se entrega, el razonamiento detrás nunca queda escrito, y seis meses después nadie sabe decir por qué una pieza crítica funciona como funciona. Cada uno de esos huecos es conocimiento que tu empresa pagó y ya no posee.

Nombra de qué depende

Qué más se rompe si esto cambia, registrado junto al cambio mismo y no en una wiki que nadie abre.

Explicita cómo falla

Qué pasa si se ejecuta dos veces o si se completa a medias, escrito donde la próxima persona realmente va a mirar.

Deja el porqué, no solo el qué

El razonamiento detrás de la decisión no evidente, para que nadie pierda una semana redescubriéndolo a los golpes.

Tres momentos donde se verifica el entendimiento

La documentación como buena intención no sobrevive a una fecha de entrega. Estos son controles integrados en el flujo de trabajo que ya existe, dimensionados para no costar casi nada en cambios rutinarios y apretar solo donde el riesgo es real.

  1. 01

    Antes de que alguien lo toque

    Mapear qué es frágil, qué no tiene dueño claro y qué tiene un alcance amplio, mientras el código todavía es desconocido. Hecho una vez, le ahorra a todos los que vienen después descubrirlo rompiendo algo.

  2. 02

    Mientras se hace el trabajo

    Salvaguardas proporcionales al riesgo real del cambio. Corregir un typo no debería cargar la misma ceremonia que tocar cómo se liquidan los pagos.

  3. 03

    Antes de entregar

    Una revisión breve del cambio terminado contra lo que efectivamente se entendió, con un veredicto que no se puede dejar pasar cuando el cambio tocó algo crítico.

04 / Caso de estudio

Engram

Quería saber si el problema de memoria que describo arriba se podía resolver de verdad, así que construí aquello que lo probaría. Engram le da a los asistentes de código una memoria del proyecto en el que trabajan — las decisiones, las lecciones, el razonamiento — y devuelve solo lo que la tarea actual necesita. Empezó como un estudio. Se está convirtiendo en producto.

Caso de estudio · SaaS en preparación

La capa de memoria que tu código nunca tuvo

  • Los asistentes retoman donde quedó la última sesión, en vez de arrancar en frío
  • El razonamiento detrás de decisiones pasadas sigue siendo localizable, por personas y por máquinas
  • Lo que demuestra ser útil aparece más seguido; lo que no, se hunde solo
Leer el caso de estudio

05 / Artículos

Notas del proceso.

Argumentos largos sobre dónde la IA ayuda de verdad y dónde te cuesta en silencio, escritos mientras los voy resolviendo.

    Publicaciones cortas en LinkedIn

    06 / Contacto

    Cuéntame dónde duele.

    Ya sea que estés definiendo dónde encaja la IA en tu operación, o entregando rápido y perdiendo el razonamiento detrás — mándame la forma del problema y te digo con honestidad si soy la persona indicada.

    Leo todo y respondo lo que pueda ayudar.