Model I/O es el contrato que define qué información lee un sistema de IA en tu modelo financiero, qué infiere de esa información y dónde tiene permiso de escribir. En FP&A, ese contrato mal definido no produce errores visibles - produce números que calculan correctamente pero con lógica incorrecta. A partir de 2026, con equipos financieros en toda la región integrando IA directamente en Google Sheets y Excel, entender y configurar este contrato es tan crítico como dominar INDEX/MATCH o las circulares intencionales de un modelo de tres estados.
Considera este escenario: tienes un modelo de tres estados que funciona. El cash sweep está vinculado al balance de deuda, que alimenta el gasto de intereses, que cierra contra el estado de resultados. Las circulares están habilitadas intencionalmente. Los rangos nombrados como Supuestos_WACC y Supuestos_TasaImpuesto hacen que el modelo sea auditable y refactorable.
Luego le pides a una IA que actualice el cálculo de intereses.
El modelo no lanza un error. Los números siguen calculando. Todo parece correcto - hasta que dos días después te preguntas por qué el DSCR no cuadra con el período anterior y descubres que la IA "arregló" tu referencia circular porque la interpretó como un error en lugar de una dependencia intencional.
Ese no es un problema de IA en general. Es un problema de Model I/O.
Por qué Model I/O es diferente en FP&A
En machine learning, Model I/O es directo: datos entran, predicciones salen. En modelado financiero es más complejo porque tu "modelo" no es un artefacto plano - es un grafo de dependencias distribuido en 8 o más pestañas, con rangos nombrados, circulares intencionales y supuestos que se propagan hacia adelante a través de cada período.
Cuando una IA lee tu libro de trabajo, su entrada es todo lo que puede ver: valores de celdas, fórmulas, estructura de pestañas, rangos nombrados y el contexto que tú le proporcionaste en lenguaje natural. Su salida es una combinación de valores escritos, ediciones de fórmulas y nueva estructura. El problema es que la mayoría de sistemas de IA tratan tu modelo como una cuadrícula plana, no como un grafo de dependencias: leen 'Estado de Resultados'!C14 y ven un valor, no el nodo final de una cadena de cálculo que empieza en Supuestos!B3.
El European Spreadsheet Risks Interest Group (EuSpRIG) documentó en Spreadsheet Errors: What We Know. What We Think We Can Do que las hojas de cálculo complejas son intrínsecamente susceptibles a errores de propagación que pasan desapercibidos durante semanas, incluso sin IA involucrada. Con un sistema de IA escribiendo fórmulas sin entender el grafo de dependencias, ese riesgo se amplifica considerablemente. Google, por su parte, deshabilita las iteraciones circulares por defecto en Google Sheets precisamente porque los sistemas externos - incluyendo las IA - las interpretan como errores a menos que se especifique explícitamente lo contrario (Use iterative calculations in Google Sheets, Google Workspace Support, 2025).
Tres patrones de fallo concentran la mayoría de los problemas:
Circulares intencionales. Los modelos de tres estados casi siempre las tienen: gasto de intereses → balance de deuda → cash sweep → gasto de intereses. La IA las interpreta como errores que corregir. Si elimina la circular para "limpiar" el modelo, este calculará sin avisar - simplemente con los números equivocados.
Rangos nombrados ignorados. Si usas =Supuestos_WACC en lugar de ='Supuestos'!$B$12 es precisamente porque si alguien mueve filas, el modelo no se cae. Una IA que escribe la dirección absoluta de la celda en lugar del nombre rompe esa protección silenciosamente. El modelo funciona hoy; falla en la siguiente reorganización de filas.
Serialización de fórmulas multi-criterio. Una fórmula como =SUMIFS('Estado de Resultados'!C:C,'Estado de Resultados'!B:B,">="&Supuestos!$B$3) puede perder su calificador de pestaña cuando una IA la reescribe en un contexto diferente. No hay error - solo un SUMIFS que ahora suma contra la hoja activa en lugar de la hoja correcta.
Comparación: sin contrato I/O definido vs. con contrato I/O configurado
| Escenario | Qué lee la IA | Dónde escribe | Riesgo resultante |
|---|---|---|---|
| Sin contrato I/O | Todo el libro de trabajo | Cualquier celda que considere relevante | Eliminación de circulares, sobrescritura de rangos nombrados, referencias a hoja incorrecta |
| Solo perímetro de lectura | Pestañas seleccionadas | Cualquier celda dentro del perímetro | Referencias cruzadas incorrectas con pestañas excluidas del contexto |
| Solo escritura restringida | Todo el libro de trabajo | Únicamente pestaña de Supuestos | Riesgo moderado; el grafo calcula desde supuestos correctos pero la lectura sigue siendo amplia |
| Contrato I/O completo | Pestañas seleccionadas + contexto declarado | Rango autorizado, revisado en diff antes de aplicar | Mínimo; todos los cambios son visibles y aprobados antes de entrar al modelo |
La diferencia entre la primera y la última fila no es configuración técnica compleja - es una decisión de arquitectura que toma menos de diez minutos aplicar y elimina la categoría más costosa de errores en modelado financiero asistido por IA.
Cómo configurar el contrato de I/O paso a paso
El principio es tratar la interacción con IA como un pipeline con puntos de control definidos, no como un chat de texto libre. Esto no significa agregar trabajo manual - significa mover la revisión al momento correcto: antes de confirmar, no después de que algo ya se rompió.
Paso 1: Define el perímetro de lectura
Antes de escribir un prompt, decide qué ve la IA. Para la mayoría de tareas de FP&A, el perímetro óptimo es:
- Pestaña de Supuestos: completa, siempre incluida
- Pestaña objetivo: la que quieres modificar
- Pestañas de referencia: solo si la tarea las requiere explícitamente
Incluir el libro de trabajo completo en cada prompt es el camino más corto a referencias cruzadas incorrectas. La IA intenta ser útil con todo lo que ve y a veces "normaliza" relaciones entre pestañas que no deberían tocarse.
Paso 2: Declara las circulares en el prompt del sistema
Este es el paso que la mayoría omite. Como Google documenta, las iteraciones circulares están deshabilitadas por defecto en Google Sheets; los sistemas de IA heredan esa interpretación a menos que el contexto indique lo contrario. Antes de cualquier tarea específica, incluye un bloque de contexto explícito:
Contexto del modelo:
- Este modelo contiene referencias circulares intencionales habilitadas.
- La circular principal: Gasto de Intereses (ER!C18) → Saldo Deuda (BS!D22) → Cash Sweep (CF!E14) → Gasto de Intereses.
- No elimines ni reemplaces estas referencias bajo ninguna circunstancia.
- Los rangos nombrados activos son: Supuestos_WACC, Supuestos_TasaImpuesto, Supuestos_CapexBase.
- Escribe siempre usando el nombre del rango, nunca la dirección absoluta de la celda.
Si la herramienta que usas permite guardar un contexto persistente del libro de trabajo, configúralo una sola vez. Aplica a todas las sesiones sobre ese archivo sin que tengas que repetirlo en cada prompt.
Paso 3: Restringe el destino de escritura
En lugar de permitir escritura libre sobre cualquier celda, define una zona de aterrizaje. La arquitectura recomendada es:
- La IA escribe únicamente en la pestaña de Supuestos (entradas discretas, filas etiquetadas, sin fórmulas propias)
- El resto del modelo calcula desde ahí hacia adelante sin que la IA toque esas pestañas directamente
Esto funciona porque si todos tus cálculos de Estado de Resultados, Balance General y Flujo de Caja referencian Supuestos!, la IA solo necesita escribir correctamente en un lugar. El grafo de dependencias hace el resto automáticamente.
Paso 4: Revisa en la vista diff antes de confirmar
ModelMonkey muestra todas las escrituras propuestas en una vista diff antes de aplicarlas - celdas modificadas, fórmulas nuevas vs. anteriores, rangos nombrados afectados. Aquí es donde verificas:
- ¿La circular del cash sweep sigue intacta? (busca
CF!E14o el nombre equivalente en las fórmulas modificadas) - ¿Las fórmulas usan nombres de rango o direcciones absolutas?
- ¿Alguna fórmula perdió el calificador de pestaña?
Este paso no es auditoría post-facto - es el gate de calidad antes de que cualquier cambio entre al modelo. La diferencia con "revisar manualmente cada celda" es que la vista diff te muestra solo lo que cambió, no todo lo que existe.
Ejemplo: actualizar supuestos de deuda en un modelo real
Supón que tu CFO te pide actualizar el modelo para reflejar una nueva línea de crédito revolvente a tasa variable (TIIE + 280 pbs) sobre un saldo máximo de $8,000,000 USD, reemplazando la deuda a tasa fija anterior.
Con el contrato de I/O configurado, el flujo es:
Prompt:
Actualiza los supuestos de deuda para reflejar una línea revolvente a tasa variable.
Nueva tasa: TIIE (actualmente 10.25%) + 280 pbs = 13.05% anual.
Saldo máximo autorizado: $8,000,000 USD.
Modifica solo la pestaña de Supuestos. No toques las fórmulas de gasto de intereses
en Estado de Resultados ni el cash sweep en Flujo de Caja.
Lo que la herramienta hace:
- Lee la pestaña de Supuestos y el contexto persistente del libro
- Identifica las celdas de tasa de interés y saldo máximo en Supuestos
- Propone los cambios en la vista diff:
Supuestos!B8de7.50%a13.05%,Supuestos!B9de$5,000,000a$8,000,000 - El Estado de Resultados, Balance General y Flujo de Caja recalculan automáticamente desde los supuestos actualizados
Lo que no ocurre: la herramienta no toca ER!C18 (gasto de intereses), no toca BS!D22 (saldo de deuda), no toca CF!E14 (cash sweep). La circular sigue intacta. El DSCR recalcula correctamente.
Si el CFO quiere ver el impacto antes de confirmar, puedes comparar el modelo antes y después directamente en la misma vista diff sin haber modificado nada aún.
El checklist antes de usar IA en tu modelo
Para cualquier modelo de tres estados que vayas a trabajar con IA en 2026, verifica estos cuatro puntos antes de empezar:
- Circulares documentadas: tienes un registro de qué circulares existen y por qué son intencionales
- Rangos nombrados activos: sabes qué nombres están definidos y cuáles fórmulas los usan
- Perímetro de lectura definido: decidiste qué pestañas incluye el contexto de la IA
- Rango de escritura restringido: la IA solo puede modificar Supuestos (o la zona que tú defines)
Con esto en su lugar, un modelo de tres estados de $42M en ingresos con 18 pestañas es tratable con IA sin riesgo de corrupción silenciosa. Sin esto, incluso cambios simples en supuestos pueden propagarse incorrectamente a través de referencias que la IA no mapeó.
El objetivo no es reducir la revisión humana - es moverla al momento correcto.
Preguntas frecuentes sobre Model I/O en modelos financieros
¿Qué pasa si la IA modifica una celda que no estaba dentro del alcance definido?
Cuando el rango de escritura no está restringido, la IA puede sobrescribir fórmulas fuera de la pestaña de Supuestos sin ninguna advertencia. El resultado típico es un modelo que calcula sin errores pero con lógica rota - por ejemplo, un gasto de intereses hardcodeado que ya no se actualiza dinámicamente desde el saldo de deuda. Por eso la revisión diff es un gate obligatorio antes de confirmar cualquier cambio, no un paso opcional al final.
¿Cómo evito que la IA rompa mis referencias circulares en Google Sheets?
Declara las circulares explícitamente en el contexto del prompt antes de cualquier tarea (ver Paso 2). Dado que Google Sheets deshabilita las iteraciones por defecto, los sistemas de IA heredan esa interpretación a menos que el contexto indique lo contrario. Con la declaración explícita, la IA trata las circulares como dependencias intencionales del modelo y no las toca.
¿Es necesario usar rangos nombrados para que el contrato de I/O funcione correctamente?
No es estrictamente obligatorio, pero es muy recomendable. Los rangos nombrados hacen el contrato I/O más robusto: la IA puede referenciar Supuestos_WACC sin importar si la fila se movió, y tú puedes verificar en la vista diff si se usó el nombre correcto o si fue sustituido por una dirección absoluta. En modelos con más de 10 pestañas, la diferencia entre un rango nombrado y 'Supuestos'!$B$12 es la diferencia entre un modelo que sobrevive a una reorganización y uno que falla silenciosamente.
¿Este enfoque aplica solo a modelos de tres estados o también a otros tipos de modelos financieros?
El mismo principio aplica a cualquier modelo con dependencias entre pestañas: valoraciones DCF, análisis de sensibilidad con tablas de datos, modelos de planificación de fuerza laboral o dashboards de KPIs operativos. Donde hay un grafo de dependencias distribuido, hay riesgo de Model I/O mal configurado. Los modelos de tres estados son el caso más crítico porque combinan circulares intencionales, múltiples pestañas interdependientes y consecuencias financieras directas cuando el cálculo falla.