Webinar
How do you respond when your AI tooling and models fail?
Description
AI is now part of how most engineering teams write, review, ship and run software. That makes the models and tools behind it a dependency like any other, except most teams haven't treated them like one. When a model provider goes down, gets rate-limited or changes behaviour, the failure doesn't look like a normal outage. It shows up as internal incidents nobody has a runbook for.
Michael Tweed from Skyscanner joins the engineers building AI at incident.io for an honest conversation about what happens when AI tooling becomes a single point of failure, and what both teams are doing about it.
In this live session, we'll be talking about:
- How AI tooling and models quietly became critical-path infrastructure, and where the single points of failure hide.
- What an AI-dependency incident actually looks like, and why it is different from a normal outage.
- How Skyscanner is approaching AI tooling resiliency today.
- What we've learned at incident.io as a company that both depends on model providers and builds AI that customers depend on.
- Practical patterns: fallbacks, degradation, detection, ownership and runbooks for AI dependencies.
- An open Q&A.
