\chapter{Conclusiones y recomendaciones}
\label{ch:conclusiones}

\section{Conclusiones}
\begin{enumerate}
  \item IPSExtractor en staging responde correctamente a humo y carga ligera de control (gateway + heartbeats).
  \item La calidad de latencia depende cr\'iticamente de no saturar el host compartido.
  \item \textbf{100\,000 facturas/mes no son alcanzables} en el laptop Ubuntu actual con el zoo Docker observado.
  \item Con infraestructura dedicada y dimensionada, el objetivo es \textbf{condicional\-mente viable}; requiere prueba de carga espec\'ifica por etapa (OCR, LLM, bot).
\end{enumerate}

\section{Recomendaciones}
\begin{enumerate}
  \item Separar IPS de MLflow/Airflow/n8n en el nodo de producci\'on/staging de rendimiento.
  \item Ejecutar ST-COUNT-01 y bench LLM solo con $\geq$3\,GiB libres y sin swap activo.
  \item Completar E2E-07 y ST-BOT-03; archivar JSON de k6 en \texttt{informes/}.
  \item Dimensionar agents bot ($N$) antes de comprometer vol\'umenes mensuales de descarga.
  \item Incorporar CI: pytest agent + store en cada PR.
\end{enumerate}

\section{Pr\'oxima campa\~na sugerida}
\begin{itemize}
  \item Ventana con MLflow detenido.
  \item Bench: 50--200 PDFs reales por etapa (OCR, LLM) midiendo p50/p95 y coste.
  \item Actualizar gr\'afica de capacidad con datos medidos (reemplazar estimaciones).
\end{itemize}