# AI Vendor Model Deprecation and Governance Page Monitoring Source: PageCrawl.io Blog URL: https://pagecrawl.io/blog/ai-vendor-model-deprecation-governance-monitoring Published: 21 September, 2026 --- Lucas runs platform engineering at a 60-person insurance software company. Four product surfaces call a language model: claims summarisation, a support copilot, a document classifier, and an internal analytics assistant. Three vendors sit behind those surfaces, and two are reached through a cloud reseller rather than the vendor's own API. When the security team asked him during a customer audit which models were running and when each one stopped working, he could not answer from anything except a spreadsheet somebody had last touched in March. The spreadsheet was already wrong. A dated model ID in the classifier had a shutdown date inside the next quarter. The vendor had published that date on a public deprecations page months earlier and emailed the API organisation owner, who was a former colleague whose account still received the mail. Nobody who could act on it saw it. The migration got done, but against a hard cutoff, during a release freeze. None of this information is secret. Every major AI vendor publishes model lifecycle status, shutdown dates, usage policies, data-retention terms, and subprocessor lists on public pages, and edits those pages continuously. The gap is not disclosure. It is that a dozen pages spread across four vendors, plus the cloud platforms reselling them on different schedules, belong to nobody in particular, so they get read exactly twice: at integration time, and during the incident. This guide covers which AI vendor pages carry the dates that break production, which governance and data-use pages belong in a vendor register, how much notice each vendor commits to, and how to turn all of it into a change feed that lands where your engineers and your compliance reviewer already look. ### Which AI vendor pages carry the dates that break production? Each vendor maintains one canonical lifecycle page listing model IDs, status, and shutdown dates. OpenAI, Anthropic, Google, and Microsoft all publish theirs publicly and edit them as schedules move. Those specific pages, not the vendor blog and not the release notes, are the pages that determine when your API calls start failing. #### OpenAI: the deprecations table OpenAI publishes a running list of deprecated models and endpoints with shutdown dates and recommended replacements on its [API deprecations page](https://developers.openai.com/api/docs/deprecations). The vocabulary matters: OpenAI uses "deprecation" to mean the model is on a clock, and attaches a shutdown date after which it is no longer accessible at all. There is no soft landing, so the date on the table is the date your integration test starts returning errors. That page changes in place. New rows get added, and existing rows get amended when a shutdown slips. Watching the whole page as text catches both. If you only care about the model IDs your services pin, a keyword rule on those exact strings keeps the monitor silent until one of your models is named. #### Anthropic: model deprecations and lifecycle status Anthropic maintains a [model deprecations page](https://docs.anthropic.com/en/docs/resources/model-deprecations) that lists each Claude model as active, legacy, or deprecated, alongside retirement dates and recommended replacements. It also documents deprecated API parameters, the category most teams forget, because a parameter removal breaks a request body that has worked untouched for a year. One detail on that page matters if you run multi-cloud. The dates published there apply to Anthropic-operated platforms. Partner platforms such as Amazon Bedrock and Google Cloud set their own retirement schedules, so the same model can carry two different end dates depending on where you call it from. #### Microsoft and Google: the platform-side clocks Microsoft publishes [Azure OpenAI model retirements](https://learn.microsoft.com/en-us/azure/ai-foundry/openai/concepts/model-retirements) as a table of deployed model versions with retirement dates, distinguishing deprecation (closed to new deployments) from retirement (existing deployments return errors). Google documents the same for its own models on the Vertex AI [model versions and lifecycle page](https://docs.cloud.google.com/vertex-ai/generative-ai/docs/learn/model-versions), with stable-version availability windows and per-model retirement dates. Both pages move independently of the model creator's schedule. A team running Claude on Bedrock and GPT-class models on Azure needs the platform pages monitored as first-class sources, not as a courtesy copy of what the vendor already said. ### Why isn't the vendor's own deprecation email enough? Vendors do send deprecation notices, but they route to the billing or API organisation owner on the account, in one vendor's own format, at one point in time. They do not reach the person who owns the migration, they do not cover the reseller platform your traffic actually runs on, and they say nothing when a date on the page quietly moves. #### The email goes to an account, not to an owner API deprecation mail is addressed to whoever holds the account or organisation role, which in most companies is a finance contact, a founding engineer, or a shared inbox created during the trial. The person who plans the migration is usually somebody else on another team. This is the same routing failure that makes [cloud SDK and API deprecation notices](/blog/cloud-sdk-api-deprecation-notice-monitoring) land in nobody's queue. Monitoring the page moves the trigger from "the right human still reads that inbox" to "the page changed." #### Dates move, and revisions are not always re-announced The announcement is one event. What follows is a series of quiet edits: a shutdown date pushed back a month, a replacement recommendation swapped for a newer model, a preview model given a much shorter runway than the generally available one it resembled. A page monitor catches the amendment because it compares current text against the last version it saw. An announcement email only ever covers the first event. #### Nothing at all is emailed for policy pages Governance is the genuinely uncovered category. Usage policies, data-retention and training-on-customer-data terms, and enterprise commitments get revised on public policy pages without a broadcast to every developer account. Subprocessor changes are a partial exception: OpenAI publishes a [sub-processor list](https://openai.com/policies/sub-processor-list/) and offers a notification signup for changes to it. That is one page, at one vendor, requiring you to have found and completed the form. Every other governance page in your register is on you. ### Which governance and data-use pages belong in an AI vendor register? Beyond lifecycle pages, four categories carry real exposure: usage and acceptable-use policies that can make a live feature non-compliant, data-use and retention terms that determine what your customer data is allowed to touch, subprocessor lists that trigger contractual objection windows, and trust or security pages that your own customers audit you against. #### Usage and acceptable-use policies Usage policies define what you are permitted to build. A tightened clause on automated decision-making, medical or legal advice, biometric inference, or minors can make a feature that shipped last quarter non-compliant with the contract you operate under. These pages are the most likely to be revised without any developer-facing announcement, because they are legal documents maintained by a different team from the docs. Watch them as long-form text so a single added sentence surfaces as a readable difference rather than a layout change. #### Data-use, retention, and training terms This is the clause your enterprise customers ask about by name: whether inputs and outputs are used to improve models, how long data is retained, whether zero-retention is available on your tier, and which region processing happens in. A revision here changes an answer you have already given in writing to your own buyers. Our guide to [monitoring terms of service changes at SaaS vendors](/blog/monitor-terms-of-service-changes-saas-vendors) covers the general pattern, and AI vendors are the highest-churn instance of it. #### Subprocessor lists A new subprocessor added under an AI vendor's data processing agreement can propagate straight into your own customer commitments, and many enterprise DPAs give the customer a fixed window to object after notice. Missing the notice means missing the window. See [subprocessor list change monitoring](/blog/subprocessor-list-change-monitoring) for how to structure the alert so a reordered table does not read as a change. #### Trust centres, certifications, and model cards Security pages carry SOC 2 and ISO certification status, penetration test cadence, and regional processing commitments. Model and system cards carry evaluation results and stated limitations that your own AI risk documentation may cite verbatim. A silent edit upstream makes your file stale without anyone touching it. Note: keep model cards out of the same folder as announcement blogs. The register wants pages that hold commitments, not pages that hold news. For release coverage, our post on [tracking AI model releases across providers](/blog/ai-model-release-monitoring-openai-google-meta) handles that separately. ### How much notice does each AI vendor actually commit to? Notice periods vary widely and depend on whether the model is generally available, a preview, or a specialised variant. Published commitments range from roughly two weeks for preview models to twelve months of availability for stable ones, with sixty days a common minimum before a retirement takes effect. The number that matters is the shortest one your stack depends on. | Vendor or platform | Published commitment | What that means in practice | |---|---|---| | OpenAI | At least 6 months for generally available models, at least 3 months for specialised variants, around 2 weeks for preview models | A preview model in production is a two-week migration risk | | Anthropic | At least 60 days notice before retirement for publicly released models, for customers with active deployments | Partner platforms such as Bedrock and Vertex set their own dates | | Azure OpenAI | GA versions available for a minimum of 12 months, with at least 60 days notice before a GA retirement | Retirement is enforced at the deployment, not just the model ID | | Google Vertex AI | Stable models available for at least 12 months after release, with short-term availability models retiring 45 days after a replacement ships | The 45-day path is the one that catches teams out | Each figure comes from the vendor's own lifecycle documentation, linked in the sections above. Two conclusions follow. Any preview or short-term model in a production path is a schedule risk you should be able to name on demand. And sixty days is a realistic worst case for a stable model, which is not long enough to discover the problem by accident. #### Build a runway map, not just an alert list For each service, write down the model ID it pins, the platform it calls, the published notice period, and the last known shutdown date. That table tells you which integration is fragile before anything is announced. A service pinned to a dated preview model on a partner platform is the one to unpin first, regardless of what any page says this week. Monitoring then keeps the table honest rather than being the thing you rely on to save you. ### How do you set up AI vendor deprecation monitoring in PageCrawl? You add each lifecycle and governance page as its own monitor, choose a tracking mode suited to the page type, set a check frequency matched to how urgent that page is, route alerts to the channel your engineers already read, and add keyword rules so only the model IDs and clauses you care about break the silence. 1. **Collect the URLs first.** List every AI model your services call, including the ones reached through a reseller. For each, capture the vendor lifecycle page and the platform lifecycle page if they differ. Then add the governance pages: usage policy, data-use and retention terms, subprocessor list, and trust or security page. Most teams end up with between eight and twenty URLs. 2. **Add each URL as a monitor.** Give it a name that says what it is, for example "Anthropic model deprecations" or "OpenAI usage policy," so an alert is readable from the notification without opening anything. 3. **Pick the tracking mode per page type.** Use reader or content tracking for long-form policy and terms pages, which extracts the main body and ignores navigation and footers. Use text or content tracking focused on the table region for lifecycle pages, where the payload is a grid of model IDs and dates. 4. **Set check frequency by urgency.** Lifecycle pages deserve the most frequent checks your plan allows, because a newly published shutdown date starts a clock. The free tier checks every 60 minutes, Standard every 15 minutes, Enterprise every 5, and Ultimate every 2. Governance pages rarely need more than a daily cadence, since the value there is not speed, it is that somebody notices at all. 5. **Add keyword rules to lifecycle monitors.** Enter the exact model IDs your services pin, including dated variants, so an alert fires when one of your models is named and stays quiet when a model you have never called is added. Our walkthrough on [conditional alerts using price, keyword, and threshold rules](/blog/conditional-alerts-price-keyword-threshold-rules) covers the syntax. 6. **Choose notification channels per audience.** Send lifecycle alerts to the engineering channel through Slack, Discord, Microsoft Teams, or Telegram, and governance alerts by email to whoever owns vendor risk. Webhooks go further and open a ticket automatically, which is the difference between an alert somebody read and a migration somebody scheduled. 7. **Turn on screenshots and keep the history.** A timestamped capture of a lifecycle table or policy page answers "when did this change, and what did it say before" during an audit, and lets you diff a clause you quoted in a customer commitment against the clause that is live today. 8. **Group the monitors into a folder per vendor.** A folder called "AI vendors" with subfolders per provider makes the register browsable, and adding next quarter's vendor becomes a five-minute job rather than a re-derivation of the whole list. #### Route the alert into the work, not into a channel Every deprecation feed fails the same way: the alert arrives, gets a thumbs-up reaction, and is never converted into work. Webhook delivery into your issue tracker fixes that. Fire the webhook on lifecycle-page changes only, create a ticket with the diff in the body, and assign it to whoever owns the service that pins the model. The same webhook can drive [AI agents reacting to website changes](/blog/ai-agents-react-website-changes-webhooks) so the ticket arrives with the affected service already named. ### How do you keep the alerts quiet enough that people act on them? Noise is the reason monitoring programmes die. Vendor documentation pages carry version pickers, feedback widgets, "last updated" stamps, and rotating navigation that change without meaning anything. Excluding those regions, choosing text-focused tracking modes, and gating lifecycle alerts on your own model IDs turns a constant trickle into a handful of alerts a quarter. #### Ignore the furniture Documentation sites are heavy. Sidebars reorder, cookie notices rotate, breadcrumbs change on a restructure, and a doc-wide banner can appear on every page at once. In PageCrawl you can mark a detected region as ignored so future checks skip it. After a couple of cycles on each vendor's docs the furniture is trained out and only body content triggers alerts. The technique is covered in our guide to [reducing website monitoring false positives](/blog/reduce-website-monitoring-false-positives). #### Gate lifecycle alerts on your own model IDs A large deprecations table gets edited for reasons that have nothing to do with you, mostly concerning models you have never called. Keyword conditions on your pinned model IDs, including dated variants, mean the page can churn all it likes and you only hear about it when your own string appears. That is the difference between eleven alerts a week and two a quarter, and quiet monitors are the ones people still trust in month six. #### Separate the two audiences Engineering wants a fast, filtered signal on shutdown dates and parameter removals. Compliance wants a complete, slower record of every policy and subprocessor edit with a screenshot attached. Running them as one undifferentiated feed guarantees each audience learns to skim past the other's alerts. Two folders, two frequencies, two channels. One honest caveat: vendors restructure their documentation, and a lifecycle page occasionally moves to a new URL. A monitor pointed at a dead URL is silent for the wrong reason, so check for page-not-found statuses when you refresh the runway map each quarter. ### What does this look like once it is running? A working setup is a folder of ten to twenty monitors, a filtered engineering channel that stays silent most weeks, an email digest for the governance pages, and a short table mapping each service to a model ID and a shutdown date. The alerts are rare, which is the point. The compounding benefit is the archive. Six months in, the monitoring history is a dated record of every lifecycle and policy change across your AI vendors, with screenshots. When a customer asks whether your AI vendor's data-use terms changed since you signed, the answer is a timestamped diff rather than a search through your own memory. That is the argument behind [continuous vendor monitoring in third-party risk programmes](/blog/continuous-vendor-monitoring-tprm) generally, and the register does double duty for teams carrying AI-specific regulatory obligations, which our post on [monitoring EU AI Act enforcement milestones](/blog/eu-ai-act-august-2026-gpai-enforcement-monitoring) covers. ### Choosing your PageCrawl plan PageCrawl's **Free plan** lets you monitor **6 pages** with **220 checks per month**, which is enough to validate the approach on your most critical pages. Most teams graduate to a paid plan once they see the value. | Plan | Price | Pages | Checks / month | Frequency | |------|-------|-------|----------------|-----------| | Free | $0 | 6 | 220 | every 60 min | | Standard | $8/mo or $80/yr | 100 | 15,000 | every 15 min | | Enterprise | $30/mo or $300/yr | 500 | 100,000 | every 5 min | | Ultimate | $99/mo or $999/yr | 1,000 | 100,000 | every 2 min | Annual billing saves two months across every paid tier. Enterprise and Ultimate scale up to 100x if you need thousands of pages or multi-team access. At an engineering hourly rate, Standard at $80/year pays for itself the first time you catch a breaking API change, a deprecated endpoint, or a silent config change before it takes down production. 100 monitored pages is enough to cover the changelogs and docs of every third-party API your stack depends on. Enterprise at $300/year adds higher check frequency, 500 pages, and full API access. All plans include the **PageCrawl MCP Server**, which plugs directly into Claude, Cursor, and other MCP-compatible tools. Developers can ask "what changed in the Stripe API docs this month?" and get a summary pulled from your own monitoring history. AI assistants can create monitors through conversation on every plan, including Free, turning your tracked pages into a living knowledge base instead of a pile of alert emails. ### Getting Started Start with the pages that can break production. Add the lifecycle page for every vendor you call and, separately, the platform lifecycle page for every reseller your traffic runs through, since the same model can carry two different end dates. That set usually fits inside the free tier, and it is the half of the register with a hard deadline attached. Then do the three things that make it stick: 1. Write the runway map. One row per service: model ID, platform, published notice period, known shutdown date. Ten minutes of work that tells you today which integration is fragile. 2. Add keyword rules for your pinned model IDs so the lifecycle monitors stay quiet until one of your models is named. 3. Add the governance pages on a daily cadence in a second folder, routed by email to whoever owns vendor risk, with screenshots enabled so the history is audit-ready. The next model retirement is already published on a page you are not reading. Put that page on a monitor this afternoon and find out on the next check rather than during the outage. --- Need more? The complete PageCrawl.io help center, with every article, is available as a single document at https://pagecrawl.io/llms-full.txt. Read it for context on anything this page does not cover.