AI Data Protection for Construction: OSHA Medical Records and the Thirty-Year Horizon
OSHA requires employee medical records to be kept for the duration of employment plus thirty years, and 29 CFR 1904.29 bars the employee name from the OSHA 300 Log for privacy concern cases. Safety teams now paste incident narratives into chat products to draft reports. This article maps the OSHA recordkeeping and confidentiality duties onto the authenticated model request.

29 CFR 1904.29 tells an employer that for a privacy concern case, "you may not enter the employee's name on the OSHA 300 Log," and requires a separate confidential list of case numbers and names. It goes further: if there is a reasonable basis to believe the description itself could identify the person, the employer may describe a sexual assault as "injury from assault" and an injury to a reproductive organ as "lower abdominal injury." A safety coordinator pasting the full incident narrative into a chat product to draft the report has sent the unredacted version to a third party. The redaction rule applies to the form and the narrative left before anyone reached the form. Ai data protection construction work has to start one step earlier than the paperwork.
I want to work through which OSHA duties model usage strains, why a thirty-year retention horizon changes the design, and what the per-request record has to hold when a compliance officer asks.
TL;DR
- Employee medical records must be kept for the duration of employment plus thirty years under 29 CFR 1910.1020(d)(1)(i), and exposure records for thirty years.
- 29 CFR 1904.29 bars the employee name from the OSHA 300 Log for privacy concern cases and permits a generalised description when the narrative itself could identify the person.
- 1910.1020(b)(4) applies the preservation and access duties regardless of how the records are made or maintained, which reaches a prompt that quotes a medical record.
- Nothing in the construction logging stack sits between a coordinator's browser and a model provider, so the copy created there has no record at all.
The duties model usage strains
Three obligations come under pressure once safety, HR or claims teams start using models on live incident data.
Retention is the one that reshapes the architecture. 29 CFR 1910.1020(d)(1)(i) requires that "the medical record for each employee shall be preserved and maintained for at least the duration of employment plus thirty (30) years," with narrow carve-outs for health insurance claims records kept separately, minor first aid records, and employees with under a year of service whose records are handed over at termination. Paragraph (d)(1)(ii) sets thirty years for each employee exposure record, and (d)(1)(iii) sets thirty years for any analysis using exposure or medical records. A security team designing log retention around a ninety-day window is designing against the wrong number by two orders of magnitude.
Confidentiality is the sharper duty. The privacy concern case rules in 1904.29 exist because the 300 Log gets shown to employees and their representatives under 1904.35(b)(2). The regulation anticipates that a narrative can identify someone even without a name, and it authorises the employer to blur the description for that reason. An external model that received the unblurred version holds the thing the rule was written to withhold.
Format neutrality closes the loop. 1910.1020(b)(4) states that "each employer shall assure that the preservation and access requirements of this section are complied with regardless of the manner in which the records are made or maintained." A record does not stop being a record because it was pasted into a text box.
Why thirty years is the design constraint
I have not seen another data protection regime in this series where the retention horizon outlasts most of the software that produced the data.
A thirty-year duty means the record has to survive vendor changes, log platform migrations, storage format changes and at least two generations of identity provider. Records living inside the application that created them will not make it that far. Write the same record to append-only storage with a stable schema and an export path, and it has a chance.
The practical consequence for AI governance is that the decision record about a model request touching a medical record inherits the horizon of the record it touched. If a coordinator asks a model to summarise an exposure history, the evidence about that request is part of how the employer demonstrates it handled the underlying record properly, and the demonstration may be requested decades later by a former employee exercising access rights under 1910.1020(e).
Why the existing controls miss it
Construction is an industry with strong physical controls and thin digital ones. Site access is badged, equipment is inspected, competent persons sign off, and the safety function is the most disciplined part of many contractors.
None of that reaches an outbound HTTPS request. The incident narrative leaves a coordinator's laptop as TLS to a reputable hostname, and the request sits in the same flow records as a hundred legitimate ones. Data loss prevention tuned for payment cards and identifiers will pass a paragraph describing an injury, a body part and a date, because prose about a workplace accident matches no pattern it holds. The general classification problem is covered in AI data classification.
The workforce pattern makes it broader. Field supervisors, subcontractor safety leads and third-party administrators all touch incident information, often on personal devices at a trailer desk at the end of a shift. My honest view is that construction safety teams are among the highest-risk AI users in any industry and get the least attention in governance programmes, because governance work starts with customer-facing products and a safety coordinator writing up a fall at 6pm appears in no product review. The unmonitored-usage problem in general is covered in shadow AI.
Agentic workflows widen it again. Contractors now run services that draft toolbox talks, summarise incident trends and pre-fill claim forms. Those services read injury records by design and call models on shared credentials, so the record names a service and never the coordinator or the case.
What the record has to carry
The record that answers a compliance officer gets written when the request leaves the authenticated user, before any response comes back.
Per request, the useful content covers the timestamp, the person authenticated through the contractor's identity provider, that person's role and project assignment, the calling application or agent, the destination provider with model name and version, the classification applied to the request body, whether the content touched a medical or exposure record, the policy version in force, the enforcement outcome, and a hash of request and response.
The case and project axes carry the weight. An access request under 1910.1020(e) or an OSHA inquiry concerns a named employee, a project or a date range, so retrieval by employee identifier, by project, by person or by time window is what makes the record usable. A record keyed only to employee and timestamp forces a reconstruction nobody completes. The cross-regulation view sits in audit trail requirements by regulation.
Two structural points. Storage has to sit outside the reach of the applications that made the requests, because the people being recorded operate the safety management system. And retention has to be designed against employment plus thirty years, not against the security team's default.
The privacy concern case is the control to enforce inline
Most OSHA data controls are written as policy and enforced by training, which asks a coordinator to redact correctly under time pressure at the end of a long shift.
An inline enforcement point can decide by content instead. A request carrying markers of a medical or exposure record routes to an internal model inside the contractor's environment, or gets refused outright. The refusal becomes a record showing the control operated at the moment somebody tried, which is worth more than a clean log. Binding agent requests back to the coordinator who triggered them keeps attribution intact when the workflow is automated, a pattern covered in agentic AI audit trail.
DeepInspect
DeepInspect is a stateless proxy between authenticated users or agents and any LLM endpoint. Identity resolution, classification of the request body, model routing and policy enforcement run inline on the HTTP request before it reaches the provider, which puts an enforcement point in front of exactly the traffic the OSHA recordkeeping scheme cares about.
Each decision writes a signed record carrying the authenticated person, the role and project context, the classification applied, the destination model and version, the policy version in force, the outcome and the timestamp. Records commit to append-only storage before the response returns, retention configures against the employment-plus-thirty-years horizon in 1910.1020(d), and retrieval by person, employee, project, model version or time range completes in seconds. The boundary covers authenticated HTTP traffic between your people or agents and the models they call. Privacy concern case determinations, the OSHA 300 Log itself, access requests and any communication with OSHA stay with the people who own them today.
If your safety coordinators are drafting incident reports in a chat tab and your logs show a hostname, the privacy concern case rule is the control already failing. Book a demo today.
Frequently asked questions
- Do the OSHA standards mention artificial intelligence?
No. Parts 1904 and 1910 describe records, access and retention without naming technology. Model usage enters scope because the records move through it, so the scoping analysis belongs with the safety director and counsel and not with a tool vendor.
- Is pasting an incident narrative into a chat product a recordkeeping violation?
The violation analysis turns on the preservation and access duties and on whether a privacy concern case was disclosed, and that determination is the employer's to make. What the employer needs is a record precise enough to make it from evidence instead of from interviews.
- Does removing the employee name make it safe?
1904.29 already answers that. The regulation contemplates that a narrative can identify someone even with the name removed, which is why it authorises a generalised description. Removing a name from a paragraph about a specific injury on a specific date at a specific site does not do much.
- Does an enterprise agreement with the model provider satisfy the thirty-year duty?
A contract about training and retention addresses vendor risk and produces no evidence about individual requests. The preservation duty in 1910.1020 attaches to the employer, and a commercial agreement does not transfer it.