RFI y Submittals: cómo controlar cambios, aprobaciones y evidencia en obra.
Lectura
7
min
Compártelo con tu red
Buildpeer
September 23, 2026
Los RFIs y submittals forman parte del intercambio de información necesario para ejecutar correctamente un proyecto. Entender qué es un RFI en construcción, y en qué se diferencia de un submittal, es el primer paso antes de poder controlarlos.
Un RFI (Request for Information) se utiliza para solicitar una aclaración cuando existe una duda sobre los planos, especificaciones u otra información del proyecto.
Un submittal, por su parte, presenta información sobre un material, equipo, producto o elemento propuesto para que pueda revisarse conforme a los requerimientos establecidos para el proyecto. Puede incluir fichas técnicas, planos de taller, muestras, información del fabricante u otros documentos.
Aunque ambos pasan por procesos de revisión y respuesta, cumplen funciones diferentes.
El reto no está solamente en generar el documento. También hay que saber qué está pendiente, quién debe responder, cuánto tiempo lleva abierto y qué información quedó como resultado de la revisión. Eso es, en el fondo, de qué se trata el control de submittals y el control de RFIs.
Por qué un RFI o Submittal sin seguimiento puede afectar la obra
Enviar un RFI no significa que la duda esté resuelta.
Mientras se espera una respuesta, la actividad relacionada puede quedar detenida o el equipo puede encontrarse sin la información necesaria para continuar de acuerdo con lo establecido en el proyecto.
Algo similar sucede con los submittals.
Un material o elemento puede necesitar una revisión antes de continuar con determinadas actividades. Si nadie tiene claridad sobre el estado del submittal, el equipo puede perder tiempo preguntando si ya fue revisado o trabajando con información que todavía no corresponde a la revisión vigente.
Un ejemplo común: el contratista instala un acabado esperando la respuesta de un RFI sobre el color exacto, porque detenerse significaría perder el día. Si la respuesta llega distinta a lo que se asumió, ese trabajo se rehace. Ninguna de las dos rutas, detenerse o seguir bajo un supuesto, es gratis. La diferencia es solo quién paga el costo y cuándo se descubre.
Con un submittal pasa algo parecido, aunque en otro momento del proceso. El proveedor entrega la ficha técnica de un equipo, y mientras nadie revisa si cumple con la especificación, la orden de compra puede quedar detenida o, peor, puede colocarse antes de tener la aprobación, arriesgando que el equipo llegue y no cumpla.
Por eso, además de registrar RFIs y submittals, es importante poder identificar cuáles siguen abiertos, desde cuándo y quién tiene pendiente una respuesta.
Qué información debería quedar registrada
Cada proyecto puede definir su propio flujo de revisión y aprobación. Sin embargo, contar con un historial claro facilita entender posteriormente qué ocurrió.
En un RFI conviene poder consultar información como:
La pregunta o aclaración solicitada.
La fecha en que se generó.
La persona o equipo responsable de responder.
La respuesta recibida.
La fecha de respuesta.
Los documentos o referencias relacionados.
En un submittal puede ser útil registrar:
El material, producto, equipo o elemento presentado.
La revisión correspondiente.
La fecha de envío.
La persona o equipo encargado de revisarlo.
El resultado de la revisión.
Los comentarios u observaciones.
La documentación relacionada.
La información exacta dependerá de los procedimientos establecidos para cada proyecto.
Lo importante es que, cuando alguien necesite revisar qué ocurrió, exista un registro y no sea necesario reconstruir la conversación a partir de correos, mensajes o recuerdos. Esto es particularmente cierto en el control de submittals, donde suele haber varias rondas de revisión antes de una aprobación final, y perder el hilo de cuál fue la última versión revisada puede costar tanto como no haber hecho la revisión.
RFI vs. submittal: cuál es la diferencia
La diferencia principal es sencilla: el RFI busca resolver una duda; el submittal presenta información para revisión conforme a los requerimientos del proyecto.
Transforma la forma en que gestionas tus proyectos de construcción.
Uno de los problemas más comunes aparece cuando una duda se resuelve mediante un mensaje, una llamada o un correo que después resulta difícil relacionar con el RFI original.
La respuesta puede existir, pero no necesariamente está disponible para todas las personas que necesitan consultarla.
Además, un RFI puede revelar que hace falta una aclaración adicional o incluso dar lugar a una modificación a mitad de obra, dependiendo de la respuesta y de los procedimientos establecidos para el proyecto.
Por eso es importante distinguir entre aclarar información y autorizar un cambio. Un RFI por sí mismo no necesariamente modifica el alcance, los planos o las especificaciones.
Cuando una respuesta sí deriva en una modificación, esa decisión debería seguir el proceso correspondiente y quedar documentada.
Con los submittals ocurre algo similar cuando existen varias revisiones de un mismo elemento.
Si el equipo no puede identificar fácilmente cuál es la revisión vigente y cuál fue el resultado de cada revisión anterior, aumenta el riesgo de trabajar con información desactualizada.
Qué cambia cuando el seguimiento queda registrado
Cuando cada RFI y submittal tiene un responsable, una fecha, un estado y un historial de respuestas, el equipo puede consultar qué sigue pendiente sin depender de preguntar constantemente por mensajes.
Esto también facilita que las personas encargadas de responder tengan contexto sobre la solicitud y puedan consultar la información relacionada.
El beneficio no está únicamente en guardar documentos. También está en poder responder preguntas operativas como:
¿Qué RFIs siguen abiertos?
¿Cuánto tiempo llevan pendientes?
¿Quién tiene pendiente una respuesta?
¿Qué submittals siguen en revisión?
¿Cuál es la revisión vigente?
¿Qué respuesta se dio anteriormente?
¿Qué documentos están relacionados con esa decisión?
Cuando esta información está organizada, el seguimiento depende menos de la memoria de las personas involucradas y resulta más sencillo consultar el historial del proyecto.
RFIs, submittals y control de versiones
El seguimiento de RFIs y submittals también está relacionado con el control documental.
Una respuesta puede aclarar cómo debe interpretarse cierta información del proyecto. En otros casos, puede iniciar un proceso que posteriormente derive en la emisión de una nueva revisión de un documento.
Por eso, no conviene asumir que la respuesta de un RFI sustituye automáticamente un plano o una especificación.
Si como resultado se genera una nueva revisión, el equipo necesita identificar cuál es el documento vigente y evitar que en campo se continúe utilizando una versión anterior.
Con los submittals sucede algo parecido. Cuando existen varias revisiones, debe quedar claro cuál es la que corresponde utilizar de acuerdo con el proceso de revisión definido para el proyecto.
Mantener relacionados los documentos, respuestas y revisiones facilita consultar el historial cuando sea necesario.
En proyectos con varios subcontratistas, esto se vuelve más delicado. Cada uno puede tener su propio criterio de qué tan seguido revisar el estado de sus RFIs o submittals, y sin un lugar común donde consultarlos, la responsabilidad de dar seguimiento termina cayendo en quien tenga más iniciativa, no en quien realmente debería tenerla.
Antes de que el próximo RFI se pierda entre mensajes
Controlar RFIs y submittals no significa generar más documentos.
Significa poder saber qué está pendiente, quién debe atenderlo, cuánto tiempo lleva abierto y qué información quedó registrada después de cada respuesta o revisión.
Cuando ese seguimiento depende de correos aislados, chats o de que una persona recuerde lo ocurrido, encontrar la información correcta puede convertirse en un problema adicional para el equipo.
Mantener un registro organizado permite que RFIs y submittals cumplan su función dentro del proyecto: resolver dudas, revisar información y dejar un historial que pueda consultarse cuando sea necesario.
Si estás buscando una forma de mejorar el seguimiento de RFIs y submittals en tus proyectos, agenda una demo y revisamos tu caso.
Preguntas Frecuentes
¿Qué es un RFI en construcción?
Un RFI (Request for Information) es una solicitud de información o aclaración relacionada con los documentos o condiciones del proyecto. Se utiliza cuando existe una duda que necesita resolverse para que el equipo cuente con información suficiente para continuar con determinada actividad. El flujo para generar y responder un RFI depende de las responsabilidades establecidas en cada proyecto.
¿Qué es un submittal y en qué se diferencia de un RFI?
Un submittal presenta información relacionada con un material, producto, equipo u otro elemento para que pueda revisarse conforme a los requerimientos del proyecto. Puede incluir fichas técnicas, planos de taller, muestras u otros documentos. La diferencia principal es que un RFI plantea una pregunta o solicita una aclaración, mientras que un submittal presenta información para revisión. Confundir ambos es común porque los dos generan un documento con fecha de respuesta, pero solo el submittal exige evidencia de cumplimiento.
¿Qué pasa si un RFI no se responde a tiempo?
Depende de la actividad relacionada. En algunos casos, el equipo puede necesitar detener una actividad hasta contar con la información necesaria. En otros, la falta de respuesta puede afectar la secuencia o el programa de trabajo. Por eso es importante identificar cuáles RFIs siguen abiertos y si alguno está relacionado con actividades próximas o en ejecución. Identificar esto a tiempo evita que el atraso se descubra solo cuando ya afectó a otra actividad dependiente.
¿Quién debe dar seguimiento a los RFIs y submittals?
Depende de la estructura y de las responsabilidades definidas para cada proyecto. Lo importante es que exista claridad sobre quién genera la solicitud, quién debe revisarla o responderla y quién es responsable de dar seguimiento a los pendientes. Sin esa claridad, es común que el seguimiento dependa de quien se acuerde de preguntar, no de un proceso definido.
¿Cómo evitar trabajar con una revisión de submittal que ya no corresponde?
Manteniendo un historial claro de las revisiones y del resultado de cada una. El equipo debería poder identificar qué revisión corresponde utilizar y consultar las anteriores cuando necesite entender el historial del proceso. Este mismo cuidado aplica al control de submittals en general: cada revisión debería quedar ligada a la anterior, no reemplazarla sin dejar rastro.
.png)
.svg){kind=small}
.png)
