Hospital fine-tunes a hosted foundation model on de-identified records
- Organization
- Lakeshore Academic Medical Center
- Vendor / dependency
- Atlas Cloud AI platform (hosted fine-tuning)
- Industry
- Healthcare
- Headline dimension
- 2.3 Fine-tuning / training data
Category 1 scores higher (MEDIUM 5.4), the headline stays on the dependency this case describes; the formula is draft and uncalibrated.
38 agent calls against Amazon Bedrock, five to ten minutes. The expert reading is never sent to the pipeline.Description
What the agents read
Lakeshore Academic Medical Center fine-tuned a vendor-hosted foundation model on 400,000 de-identified discharge summaries to build a coding assistant. The fine-tuning job ran on the Atlas Cloud AI platform under the hospital's enterprise agreement, with customer-managed encryption keys and a data-residency commitment for the training-data bucket. The agreement says enterprise data is not used to train Atlas's own models.
It does not say how long the uploaded training set and the fine-tuning checkpoints are retained after the job completes, whether they are covered by the residency commitment, or what deletion service level applies if the hospital terminates. The de-identification was performed under the hospital's expert-determination process, but re-identification risk was assessed for internal use, not for indefinite retention by a third party. The assistant is used by a single coding team. The hospital opted in to fine-tuning deliberately and could rebuild the model with another vendor from its own copy of the data.
Expert reading by hazard class
For comparison after a live run; never sent to the pipeline
| Class | Carried by | Score | Rating |
|---|---|---|---|
| 1 Whose AI brain is this, really? | 1.2 Model weight custody / control | 5.4 | MEDIUM |
| 2 What are we feeding it? | 2.3 Fine-tuning / training data | 3.4 | LOW |
| 3 What does it create from our data: and where does THAT go? | 3.6 Cached / derived artifacts | 2.0 | LOW |
| 4 Who's deciding what the AI sees and does? | 4.4 Guardrail / safety filter layer | 3.3 | LOW |
| 5 Which humans are actually looking at our stuff? | 5.3 Support / debugging access | 3.2 | LOW |
| 6 Who's holding the steering wheel? | 6.1 Centralized control plane / admin console | 2.7 | LOW |
| 7 How many companies are really in this chain: and did we agree to it? | 7.3 Infrastructure providers beneath the AI vendor | 1.9 | LOW |
Findings
Expert 'what we found' per class, with the vector each score is computed from
- MEDIUM5.4
1 Whose AI brain is this, really?
1.2 Model weight custody / controlThe fine-tuned model exists only as checkpoints inside Atlas. The hospital holds the training data but cannot export the weights, so if Atlas withdrew the base model or the hospital left the platform, the assistant would have to be rebuilt from scratch on another base model, with different behaviour. Atlas announces base-model retirements twelve months ahead.
The hospital owns the data but not the model it paid to create; leaving means starting over.
SOV:1.0/AV:N/AC:H/AT:N/PR:L/UI:N/VC:N/VI:L/VA:H/SC:N/SI:N/SA:L/E:P/CR:H/IR:M/AR:M/R:I/V:D/RE:H · Medium
- LOW3.4
2 What are we feeding it?
2.3 Fine-tuning / training dataFour hundred thousand de-identified discharge summaries were uploaded for the fine-tuning job. They sit behind customer-managed keys in the committed region, but the agreement is silent on how long they and the job's checkpoints are kept after completion and on the deletion service level at termination. The de-identification was assessed for internal use, not for indefinite third-party retention.
The data is well protected today; what is undefined is how long it stays there and on whose say-so.
SOV:1.0/AV:N/AC:H/AT:P/PR:L/UI:A/VC:H/VI:L/VA:N/SC:L/SI:N/SA:N/E:P/CR:H/IR:M/AR:M/S:P/AU:N/R:U/V:D/RE:M/U:Green · Low
- LOW2.0
3 What does it create from our data: and where does THAT go?
3.6 Cached / derived artifactsThe fine-tuning job produced evaluation samples and training logs that quote fragments of the training summaries. They are stored in the hospital's own tenancy under its keys and can be deleted by the hospital.
Derived artefacts exist but stay inside the hospital's tenancy under its own keys.
SOV:1.0/AV:N/AC:H/AT:P/PR:L/UI:A/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N/E:U/CR:H/IR:M/AR:M/R:U/V:D · Low
- LOW3.3
4 Who's deciding what the AI sees and does?
4.4 Guardrail / safety filter layerAtlas's platform guardrails screen the coding assistant's inputs and outputs. The hospital configures them itself and can see the rules, though Atlas can update the underlying filter models.
The hospital holds the filter settings; the vendor holds the filter.
SOV:1.0/AV:N/AC:H/AT:N/PR:L/UI:P/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N/E:U/CR:H/IR:M/AR:M/R:U/V:D · Low
- LOW3.2
5 Which humans are actually looking at our stuff?
5.3 Support / debugging accessAtlas support can access job metadata and logs when the hospital opens a ticket, but not the training data or checkpoints, which are encrypted under the hospital's keys. Access is logged to the hospital's audit trail.
Support access is narrow, key-gated and logged: the way it should be.
SOV:1.0/AV:N/AC:H/AT:P/PR:L/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N/E:P/CR:H/IR:M/AR:M/R:U/V:D · Low
- LOW2.7
6 Who's holding the steering wheel?
6.1 Centralized control plane / admin consoleThe platform console is part of the hospital's existing cloud tenancy, in the committed region, behind hospital single sign-on. Atlas can change console features but not the hospital's policies or keys.
Controls sit where the hospital already governs its cloud.
SOV:1.0/AV:N/AC:H/AT:N/PR:L/UI:N/VC:N/VI:L/VA:L/SC:N/SI:N/SA:N/E:U/CR:H/IR:M/AR:M/R:U/V:D · Low
- LOW1.9
7 How many companies are really in this chain: and did we agree to it?
7.3 Infrastructure providers beneath the AI vendorAtlas is both the AI platform and the infrastructure provider, so the chain is one company deep and covered by the hospital's existing cloud assurance. The hospital chose this arrangement knowingly.
The shortest chain in this set: one contracted company, already assessed.
SOV:1.0/AV:N/AC:H/AT:P/PR:L/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:L/E:U/CR:H/IR:M/AR:M/R:U/V:D · Low
What the organization should do next
- Amend the agreement to state retention periods and a deletion service level for the training set and checkpoints, and confirm both are inside the residency commitment.
- Re-run the expert-determination re-identification assessment against the new assumption of multi-year third-party retention.
- Request checkpoint export, or at least a contractual commitment to twelve months' access after termination, to reduce the rebuild cost.
- Record the fine-tuned model in the hospital's AI inventory with its base-model retirement date.
Questionnaire answers
22 of 22 answered · these seed the metric priors
Show all 22 answers
| OP-CR | How damaging would unauthorized disclosure of the data this AI dependency handles be for your organization?Severe: regulated, personal, privileged or trade-secret data |
| OP-IR | How damaging would an undetected change in this dependency's behaviour or outputs be?Moderate: outputs feed business decisions with some review |
| OP-AR | How long could your organization operate acceptably without this AI capability?Days: material business disruption |
| CL-CATEGORY | Which taxonomy category best describes the dependency you are assessing?Data input: prompts, RAG documents, fine-tuning data, tool-call parameters |
| D-AV | Where does this dependency run, and who can reach it?In the vendor's own cloud, reached directly over its API |
| D-AC | What would the vendor, a subprocessor, or a legal authority have to overcome to access the data or change the service?Real barriers: customer-managed encryption keys, data-residency carve-outs, contractual access restrictions |
| D-AT | Can the vendor exercise this control at any time, or only when something specific happens?Only upon a specific event: sanctions designation, litigation hold, security incident, product decision |
| D-PR | Who is in a position to exercise this control?Only the primary vendor we contract with |
| D-UI | Does the exposure require any action by your organization?We must opt in, accept an update, or take another affirmative step |
| D-VC | At this dependency itself, how much confidentiality could be lost?Full: the exercising party can read the sensitive data outright |
| D-VI | At this dependency itself, how much could its behaviour or outputs be altered without your knowledge?Partial: limited or detectable alteration |
| D-VA | At this dependency itself, could the capability be withdrawn or degraded by the exercising party?None: we could keep operating this component |
| D-SC | Beyond this dependency, how much confidentiality could be lost at other systems or parties?Partial |
| D-SI | Beyond this dependency, could downstream systems or decisions be altered?None |
| D-SA | Beyond this dependency, what would stop working, and could anyone be harmed?Nothing downstream is affected |
| D-E | Has this kind of control actually been exercised against organizations like yours?Demonstrated in research or incident reports, not confirmed against our stack |
| D-R | If the vendor relationship ended tomorrow, could you reconstitute this capability elsewhere?Yes, with manual migration effort (re-embedding, re-integration, re-contracting) |
| D-V | How many of your AI workloads depend on this component?One narrow workload |
| D-S | Would a loss of control here, on its own, trigger a reportable regulatory violation?Yes |
| D-AU | Could the loss event happen to all of the vendor's customers at once, with no case-by-case decision?No, it requires a discrete action against us specifically |
| D-RE | How much effort would it take to exit this dependency or otherwise mitigate the exposure?Moderate: a project, but no re-architecture |
| D-U | How does the vendor notify you of sovereignty-relevant changes (model versions, subprocessors, hosting, terms)?Disclosed with some advance notice, not contractually guaranteed |
Notes: Expert reviewed. Primary vector derived from the questionnaire answers; category vectors and findings confirmed on review. Deliberately the best-controlled case in the set: barriers and opt-in keep most categories Low. Category 1 scores higher than the headline because the non-portable checkpoints follow from the fine-tuning decision; the headline stays on 2.3 because the retained training data is the dependency the scenario describes.