Reported operating use · Banking / engineering operations
AI disaster recovery evidence: Nubank example
Nubank, in an AWS article, describes using AWS DevOps Agent to correlate metrics, logs and alerts from controlled disaster-recovery exercises and generate a report for engineers. Argo and AWS FIS run and bound the tests. The article does not isolate the agent's contribution.
Interpret disaster-recovery test evidence and prepare recovery reports
Nubank
Reported use in controlled resilience exercises
A published third-party example, not a Nuvepro customer case or evidence of a partnership.
The workflow at a glance
Recovery-test evidence for engineering review
Illustrative summary of the published account
Reported work components. Their arrangement does not imply a fixed execution order or simultaneous work.
- Experiment
Synthetic traffic and bounded faults
Argo coordinates exercises; AWS FIS bounds experiments and ends faults.
- Agent context
Scenario, time window and objectives
An internal service supplies recovery conditions to AWS DevOps Agent.
- Evidence report
Metrics, logs and alerts through MCP
The agent correlates signals and produces reports for engineers.
What the source reports
In an AWS article coauthored by Nubank staff, the bank describes One Step Execution for controlled disaster-recovery exercises. Argo orchestrates synthetic traffic and fault injection; AWS FIS bounds the experiment and ends faults. An internal service supplies the AWS DevOps Agent with the scenario, time window and recovery conditions. Through internal MCP servers, the agent correlates metrics, logs and alerts and generates a report for engineers. Three scenarios cover unavailable zones, unavailable clusters and simulated data destruction. The article reports platform-level results across nine tests in 2026; it does not isolate the agent’s contribution.
Reported technology: AWS DevOps Agent, AWS FIS, Argo Workflows and K6. Scope and outcomes are source-reported.
What the enterprise environment would need
The following is a proposed project design for an enterprise doing similar work. Published details are marked; the remaining systems, data and scenarios would be agreed for your project.
Proposed practice environment
Prepare a recovery report that can be reproduced
Illustrative project design to scope with your enterprise.
- 1 · Set up the environment
Disposable service replica and bounded faults
Pin synthetic transactions, recovery objectives and approved evidence windows.
- 2 · Preparation and agent contributions
Agent drafts evidence-linked recovery claims
Attach telemetry and identify conflicting signals or unresolved objectives.
- 3 · Independent checks
Independent objective comparison
Compare claims with fixed transaction outcomes and measured recovery conditions.
- 4 · People decide acceptance
Engineer and risk owner review conclusions
Accept only reproducible recovery evidence; retain every unmet or uncertain objective.
A reviewable evidence package
A recovery report with evidence links, contradictions and unresolved objectives.
If a check fails → withhold acceptance.
Infrastructure appears healthy while synthetic transactions fail. Withhold the successful-recovery conclusion.
Failure or owner rejection returns to review
- Hold
- → 2 · Revise work
- → 3 · Rerun independent checks
- → 4 · Owner review
Operating boundary. Fault permissions remain separate from reporting; ending a fault is not proof of service recovery.
- Proposed enterprise environment
- Use a disposable service replica with synthetic transactions, pinned recovery objectives, bounded fault scenarios and read-only evidence access. Keep fault permissions separate from the report-writing agent.
- Proposed practice project
- Prepare a recovery report from a fixed experiment window, attach each conclusion to telemetry, identify conflicting signals and hand unresolved recovery claims to the responsible engineer.
- People and agent responsibilities
- In this proposed practice, the agent drafts evidence-linked findings. Engineers approve the experiment boundaries and independently accept or reject recovery claims; a risk owner reviews the final evidence package.
A proposed simulation
An illustrative practice design derived from this work, not an executed assessment.
Proposed: produce an evidence-linked recovery report that exposes uncertainty before operational acceptance.
Review gate: A reviewer can reproduce every recovery conclusion from the supplied evidence and identify every unresolved objective.
Challenge the result: Provide healthy infrastructure metrics alongside failed synthetic customer transactions; the report must withhold a successful-recovery conclusion.
What needs checking
- Proposed: an independent checker compares each reported recovery assertion against fixed synthetic transaction outcomes and recovery-objective measurements.
- Proposed: verify that evidence outside the approved test window cannot silently influence the recovery conclusion.
- Proposed: confirm that stopping a fault does not automatically count as successful service recovery.
Review environment fidelity, human capability and agent performance separately. The enterprise’s accountable owners decide acceptance of the shared workflow and any operating use.
Questions about this example
- What does Nubank use AI for in disaster recovery?
- In an AWS article coauthored by Nubank staff, AWS DevOps Agent receives the scenario, time window and recovery conditions, then correlates metrics, logs and alerts through internal MCP servers. It generates a report for engineers.
- Who reviews Nubank's recovery reports?
- The source says the agent produces a report for engineers, and Argo and AWS FIS bound each experiment and end faults. How engineers accept recovery claims is not detailed. A proposed design, not Nubank's, adds independent acceptance and risk owner review.
- How strong is the evidence for Nubank's use?
- It is reported use in controlled resilience exercises, from an AWS and customer account. It reports platform-level results across nine tests in 2026 but does not isolate the agent's contribution, and it gives no report-error rate or independent confirmation of regulatory acceptance.
- What would an enterprise need to build something similar?
- This is Nuvepro's proposed design, not Nubank's. It would need a disposable service replica with synthetic transactions, pinned recovery objectives, bounded faults and read-only evidence access. An independent checker would test whether healthy metrics with failed transactions still withhold a recovery conclusion.
Shape this around your enterprise
Bring a similar workflow and the people responsible for it. Together, define the records and systems to use, the result your team will build or configure, and how its owners will check it. Nuvepro scopes the simulation, environment and preparation. Agree any existing-agent evaluation, implementation assistance and production responsibilities separately.
Sources and limitations
Curation review: . This is the date this source example was reviewed, separate from source publication dates.
- The source is an AWS and customer account, not an independent audit.
- The article does not provide the full test evidence, report-error rate or independent confirmation of regulatory acceptance.
- Published platform gains cannot be attributed solely to the agent; future scheduling and reporting plans are not current delivered scope.
- Proposed practice and checks are illustrative designs, not an executed Nuvepro demonstration.
- AWS and Nubank: How Nubank automated disaster recovery with the AWS DevOps AgentSource publication: 2026-10-28
More it operations examples
- AI cloud incident investigation: Eon exampleEon
- AI incident investigation: InEight exampleInEight
- AI IT service requests: Redpanda exampleUnnamed enterprise customer reported by Redpanda
- AI network config review: Microsoft Digital exampleMicrosoft Digital