RFFR’s "Fully isolated" is a higher bar than it sounds
The internal-use carve-out in DEWR’s AI framework is real. It is also narrower than most providers read it, and where it runs out, the Department’s own two documents point in different directions.
Most providers have reached the same conclusion about internal AI, and they have reached it calmly.
The reasoning runs like this. The Department’s Third-Party AI Assessment Framework is about AI in service delivery. The tool in question is not in service delivery. Nobody in a participant-facing role touches it. It drafts board papers, or summarises policy, or helps the finance team reconcile something. So it sits outside the Framework, and the assessment process belongs to somebody else.
That is a fair reading, and the Framework invites it. The Scope section says the Framework "does not apply to how organisations use AI for internal business purposes, such as human resources systems, when those uses are unrelated to delivering services for the Department and are fully isolated from all service-related systems and data" (Framework, Scope, page 4). An HR screening tool that never touches departmental data is exactly the case the drafters had in mind.
So the carve-out is real. The question is what the second half of that sentence costs you.
What isolation actually requires
"Fully isolated from all service-related systems and data" is a technical claim, not a description of who uses the tool. It is about wiring.
Four things end it:
• A shared tenant. The tool sits in the same Microsoft 365 or Google Workspace tenancy as your case management environment.
• A shared identity provider. Staff sign in with their normal work account. Single sign-on is convenient, and it is also a connection.
• A shared data store. The tool can reach a SharePoint site, a shared drive or a database that also holds service delivery records.
• Any integration at all. A reporting connector, a scheduled export, a workflow automation, a plug-in that pulls from a service system.
Any one of these and the tool is not isolated. Not mostly isolated. Neither document offers a partial state, and neither glossary defines the term, which leaves the work of defining and evidencing the boundary with you.
If the answer to "show me the boundary" is a shrug, you do not have a carve-out. You have an assumption.
Here is what that looks like in a real organisation. The executive team licences a summarisation tool for board papers and policy documents. No participant information goes near it. It sits in the same Microsoft 365 tenant as the case management system, and everyone signs in with their usual work account.
That tool is not isolated. Nobody did anything improper, nobody made a bad decision, and the carve-out still does not apply.
If you want to check where your own tools sit, the scope self-check runs through the same questions: free system check for up to 10 AI tools.
Where the two documents disagree
This is the part worth checking for yourself, and the references are here so you can.
The Framework is unambiguous. "AI may be used for internal tasks that are unrelated to service delivery if the AI system is fully isolated from all service-related systems and data. If isolation cannot be guaranteed, AI must not be used" (Framework, Third-Party Requirements for AI Use, page 5). Attachment A says it again in the Step 1 Initial Check: "If isolation is not possible, the AI must not be used" (page 8). The Step 1 process map on page 10 runs the question "Can isolation be ensured?" to a single box marked "Do not proceed".
The Application Form takes a different path. Under When to Use the Form: "You must complete the Form if ... the AI system is not directly related to service delivery but cannot be fully isolated" (Application Form, page 1).
Same set of facts. Internal use, isolation not established. One document says the AI must not be used. The other says you must apply.
I am not going to tell you which one governs, because I do not know, and neither does anyone who has not asked the Department. What I can tell you is that the two positions cannot both be operating, and that a provider relying on either one should be able to say which it chose and why.
What to do while it stands
My view: Treat unconfirmed isolation as in scope. That is the conservative reading, and it is the one that holds up when an assessor starts asking questions. Again, this is my view, but not isolated should be treated the same as something directly impacting Service Delivery.
Here's what I would do; four things, and they fit on one page:
1. Write the boundary down. Tenant, data store, identity provider, integrations. Name the actual systems, not the categories.
2. Record who confirmed it and when. Isolation is a state, not a property. It was true on the day your IT lead checked it.
3. Re-test on change. A new connector, a tenant migration, an SSO rollout, a vendor release that quietly adds a feature. Each of those can end isolation without anybody deciding anything.
4. If you cannot evidence it, act as though the tool is in scope, and minute that you chose to. A deliberate decision you can explain is a governance position. The same outcome arrived at by default is a finding waiting to happen.
Why this lands now and not at the annual review
Two sentences from Attachment A explain the timing. "Each proposed use of AI requires a separate application and written approval from the Department before it can be implemented" (page 8). And: "Approved AI use cases will be reviewed annually as part of the RFFR process" (page 8). Approved use is monitored under Right Fit for Risk accreditation (Framework, page 6).
Read those together. Approval comes before implementation. Review comes annually. So, an isolation assumption that does not survive contact with an assessor is not a problem you fix at the review. By then the tool has been running for a year in a category the Department may not accept, and the approval you would have needed had to come first. Neither document offers a retrospective path. It might not be discovered until the review, but by then it's too late if you've been running an unapproved AI. It's not clear how the department will react to this.
That is the urgency, and it is an honest one. Nobody is coming for you this quarter. It is simply that the cheapest moment to test the assumption is now, and the most expensive one is when somebody else tests it for you.
If you want to check where your own tools sit, the scope self-check runs through the same four tests: free system check for up to 10 AI tools.
Not sure where to start?
Tell me what you're facing. You'll get a straight answer on whether this is the right piece of work, and what it would involve.