AI is becoming part of ordinary professional software. It now appears inside email platforms, meeting tools, document systems, practice management products and specialist legal technology, as well as standalone chatbots.
The potential uses in a migration practice are easy to identify. Document extraction, summarisation, chronology building, file comparison, first drafts and administrative support are all natural candidates.
The professional duties around client information are familiar. The architecture behind an AI product usually is not.
What happens after a document is uploaded? Where is it processed? How long is it retained? Which other providers receive it? Can vendor personnel access it? Is it used to improve a model? What does deletion actually remove?
These questions are rarely answered in full on a product homepage. The answers may also change depending on the subscription, account settings and way the software is accessed.
For registered migration agents, OMARA’s guidance published on 5 March 2026 adds an important threshold issue. Its agent-facing information confirms that RMAs remain responsible for immigration assistance provided with the help of AI and warns that sharing a client’s personal details through an AI tool may breach the duty of confidentiality under section 35 of the Code of Conduct. OMARA’s consumer information also states that written consent is needed before personal details are entered into an AI platform or system.
That makes consent part of the starting point for an RMA. It does not answer whether a particular system is suitable for the information involved.
A useful assessment can be organised around four questions:
- Is the proposed use appropriate?
- Has the use been properly explained and authorised?
- Is the particular product suitable?
- Can its use be controlled inside the practice?
A note on scope
This article is written primarily for registered migration agents and uses OMARA’s 5 March 2026 guidance as its regulatory starting point.
Australian legal practitioners providing migration legal services operate under a separate professional framework. Dual regulation ended on 22 March 2021, and lawyers holding the appropriate practising certificates are regulated through the legal profession framework rather than as registered migration agents. The applicable professional legislation, conduct rules and regulator will depend on the practitioner’s jurisdiction.
The technical questions below are equally relevant to immigration law practices. The professional analysis is different. Lawyers should consider confidentiality, privilege, disclosure, consent and supervision under the framework applying to their practice. OMARA’s consumer statement about written consent should not be presented as the source of a lawyer’s professional obligations.
This article focuses on assessing the AI product, rather than explaining the underlying professional duties of either RMAs or lawyers.
On this page
- Part 1: Is the proposed use appropriate?
- Part 2: Has the use been properly explained and authorised?
- Part 3: Is the particular product suitable?
- Part 4: Can its use be controlled inside the practice?
- The one-page checklist
Part 1: Is the proposed use appropriate?
Start with the task, not the product
It is difficult to approve an AI product in the abstract.
Using a tool to improve a generic internal email is different from uploading a complete client file. Extracting dates from selected documents is different from reviewing health, identity, financial and relationship evidence across an entire matter. Transcribing a public webinar is different from recording a client conference.
Before reviewing security pages or contractual terms, define what the practice is proposing to do.
A useful description should identify:
- the task being performed;
- the documents or information involved;
- whether personal or sensitive information will be included;
- the output the system will produce;
- who will review that output; and
- how the output will be used.
The OAIC’s Guidance on privacy and the use of commercially available AI products recommends assessing a product against its intended use. That includes considering whether it has been tested for that use, how human oversight will operate, who will have access to personal information and what privacy and security risks arise. The OAIC also cautions against adopting AI simply because it is available.
The outcome does not need to be a blanket approval or rejection. A product may be suitable for one defined task and unsuitable for another.
Defining the use case also limits gradual expansion. A system initially approved for generic drafting can otherwise become a place where complete client records are uploaded without anyone revisiting the original assessment.
Consider what information the task actually requires
A full matter should not be the default input simply because the software accepts it.
Depending on the task, the practice may be able to use:
- selected documents;
- particular pages;
- a limited factual extract;
- redacted records;
- carefully de-identified material; or
- synthetic data.
Removing a name and passport number does not necessarily make a migration file anonymous. A combination of nationality, dates, family composition, travel history, occupation, location and personal circumstances may still make an individual reasonably identifiable.
The OAIC recommends using or disclosing only the minimum amount of personal information required for the relevant purpose and considering privacy-preserving techniques where they do not compromise the intended result. It also warns that information entered into some AI systems may be difficult to track, control or remove, and may carry a risk of re-identification even when described as de-identified.
There will be tasks where removing identifying context significantly reduces the value of the analysis. In that case, the assessment should proceed on the basis that identifiable information is being used. Describing a file as de-identified does not make it so.
Consider the consequence of a poor output
Product security is only one side of the risk.
An AI system used for administrative formatting presents a different risk profile from one used to extract critical dates, reconcile factual claims or assist with substantive work. The greater the consequence of an incomplete or inaccurate result, the stronger the testing, review and supervision should be.
OMARA’s agent-facing guidance is direct on responsibility. An RMA who provides inadequate or inaccurate information remains responsible for it, regardless of whether AI contributed to the work.
The assessment should therefore record where the system assists and where professional judgment remains with the practitioner. “Human review required” is more useful when the review step is actually defined.
Who reviews the output? What are they checking? What source material remains available to them? What happens if the system cannot process part of the file?
Those questions are generally more valuable than a broad statement that the tool is only an assistant.
Part 2: Has the use been properly explained and authorised?
OMARA’s position for RMAs
OMARA published its specific AI guidance on 5 March 2026.
The guidance says RMAs may use AI while providing immigration assistance, but remain responsible for the assistance they provide. It also confirms that the Code of Conduct applies to AI use and warns that sharing a client’s personal details through an AI tool may breach the section 35 duty of confidentiality.
The wording on consent appears in OMARA’s consumer-facing information. It says an RMA should explain the proposed use of AI to the client in advance and states:
RMAs need your written consent before they enter your personal details into an AI platform or system.
The provenance matters. This is OMARA communicating its position to consumers, rather than wording taken directly from section 35 or another provision of the Code.
On OMARA’s published position, an RMA proposing to enter personal details into an AI platform or system should first explain that use and obtain written client consent.
What should the explanation cover?
OMARA’s published information does not prescribe a consent form or detailed disclosure script.
The explanation should still give the client enough information to understand what is proposed. Depending on the use, that may include:
- the general purpose for using AI;
- the types of information or documents that may be processed;
- whether an external technology provider is involved;
- the main arrangements applying to the information; and
- any material limitations relevant to the client’s decision.
A clause saying only that the practice “may use technology” gives the client very little information. A technical description of every model, database and subprocessor is unlikely to assist either.
The sensible middle ground is a clear account of what the system will do with the client’s information and why it is being used.
The consent should also correspond with the use that was explained. If a product is initially used for transcription and later used for broader analysis of the matter, the practice should consider whether the original explanation still covers the new use.
Consent does not approve the product
Consent and product due diligence serve different purposes.
Client consent does not establish that the provider’s security is adequate. It does not clarify retention, hosting, human access, subprocessors or incident response. It does not make an unsuitable product suitable, or transfer the RMA’s responsibility to the vendor.
Consent addresses what the client has been told and agreed to.
Product due diligence addresses whether this particular system should receive the information in the first place.
Immigration law practices
For immigration lawyers, disclosure to an AI provider may raise questions about professional confidentiality, privilege, informed consent, third-party access and supervision.
Those questions must be considered under the legal profession framework applying to the practitioner. Since 22 March 2021, lawyers providing migration legal services under the appropriate practising certificate have been regulated as legal practitioners rather than registered migration agents.
An immigration law practice can use the technical checklist in this article without treating OMARA’s consumer-facing consent statement as a rule that directly governs lawyers.
Part 3: Is the particular product suitable?
Public chatbots and professional systems are not equivalent
The fact that two products use the same underlying model does not mean they handle client information in the same way.
A model might be accessed through:
- a free public chatbot;
- an individual paid account;
- a business or enterprise workspace;
- an application programming interface;
- a specialist legal or migration product; or
- an AI feature inside another software platform.
Each arrangement may have different retention periods, data-use terms, administrative controls and contractual protections.
As a matter of best practice, the OAIC recommends that organisations do not enter personal information, particularly sensitive information, into publicly available generative AI tools because of the significant and complex privacy risks.
A commercial or specialist product still needs to be assessed. It may provide defined contractual and technical protections, but those protections should be verified rather than inferred from the type of product.
The practical question is not simply whether the product uses AI.
It is what happens to client information under this product, this subscription and these settings.
Identify the exact product, plan and settings
“We use ChatGPT”, “we use Claude” or “our practice system has AI” does not identify the service being assessed.
Record the exact:
- product;
- subscription;
- workspace type;
- method of access;
- relevant account settings; and
- optional features being used.
ASD’s Australian Cyber Security Centre published Artificial intelligence for small business on 14 January 2026. Its checklist recommends confirming what information the product collects, where it is stored, who owns it, whether business data is used to train AI models and how the vendor handles security incidents. It also recommends reviewing the provider’s data ownership, protection, use and storage terms.
The assessment should follow the actual product arrangement, not the general reputation of the model provider.
An AI feature embedded in a familiar practice platform may also involve a separate model provider with which the practice has no direct relationship. The surrounding software may already be approved, but that does not automatically answer how the new feature handles information.
Map the full data path
Uploading the document is only the visible part of the process.
An AI-enabled system may create or transmit:
- the original file;
- extracted text;
- document metadata;
- prompts and system instructions;
- generated outputs;
- embeddings or other derived representations;
- diagnostic records;
- activity and security logs; and
- backups.
Different providers may handle different parts. The company selling the product might use one provider for hosting, another for document extraction and another for model processing.
The useful question is not simply:
Where is the PDF stored?
It is:
What information is created or transmitted during the complete process, and which organisation receives each part?
The OAIC recommends examining a product’s data flows, whether the developer or other third parties can access information entered into or generated by the system, and whether features that disclose information can be disabled or otherwise controlled.
A provider should be able to explain this architecture in plain language. A migration practice should not have to reconstruct it from scattered marketing pages and generic privacy terms.
Look closely at data-residency claims
Australian data residency can be a valuable control. The claim still needs a definition.
Does Australian hosting apply to:
- original files;
- extracted text;
- prompts;
- outputs;
- application databases;
- logs;
- backups; and
- disaster-recovery copies?
Does it cover both storage and processing?
A product may keep the original document in an Australian data centre while sending extracted text elsewhere for model processing. Another may operate its principal application in Australia but use overseas support or monitoring services.
“Hosted in Australia” is therefore not a complete description of the data path.
Ask the provider to identify:
- where each material category of information is stored;
- where model processing occurs;
- whether an overseas provider can access or modify the information;
- what happens during support or incident investigation; and
- whether processing locations can change.
Where APP 8 may enter the picture
Data residency and APP 8 are related, but they are not the same question.
Where a practice is an APP entity, APP 8 applies when it discloses personal information to an overseas recipient. Before making that disclosure, the entity must generally take reasonable steps to ensure the recipient does not breach the Australian Privacy Principles in relation to the information. Section 16C may also make the APP entity accountable for certain acts or practices of that overseas recipient.
The OAIC explains in Chapter 8 of the APP Guidelines that disclosure involves making information accessible outside the entity and releasing its subsequent handling from the entity’s effective control. Routing information through an overseas server is not automatically a disclosure. It will usually remain a “use” until an overseas recipient can access or modify the information, although arrangements involving overseas contractors will often amount to disclosure.
This is why the data map matters. “Processed overseas” and “disclosed to an overseas recipient” are not automatically interchangeable, but neither should be left unknown.
Privacy Act coverage and the application of APP 8 depend on the entity and the particular arrangement. Data location should be identified as part of the assessment rather than treated as a marketing preference alone.
Ask what “not used for training” means
A statement that customer content is not used to train the model is helpful.
It may leave several other uses unanswered.
Ask whether information can be used for:
- foundation-model training;
- fine-tuning;
- product improvement;
- quality evaluation;
- testing;
- safety monitoring;
- abuse detection;
- feedback analysis; or
- human review.
Some of these activities may be legitimate and tightly controlled. The practice still needs to know whether they occur.
The answer may also differ according to:
- subscription level;
- workspace settings;
- whether a user submits feedback;
- the feature being used; or
- the underlying model provider.
ASD’s ACSC recommends confirming whether business information will be used to train AI models and reviewing vendor terms dealing with data ownership, protection, use and storage.
“We do not sell your data” answers a different question.
“We do not use customer data to train foundation models” may still leave open the use of information for testing, evaluation or product improvement.
Specific language is more useful than a broad assurance.
Separate retention from deletion
Retention is rarely one period.
A document may disappear from the user interface but remain temporarily in:
- an operational database;
- a backup;
- a security log;
- an error-monitoring system; or
- a subprocessor’s service.
Ask how long the provider retains:
- original documents;
- extracted text;
- prompts;
- outputs;
- matter histories;
- activity records;
- backups; and
- information associated with a closed account.
Then ask what deletion removes.
Can the practice delete one document? A complete matter? All information connected with the workspace? Does deletion extend to extracted content, derived data and generated outputs? When are backup copies removed?
“Deleted when no longer required” is not a retention period. Required for what purpose, and for how long?
The OAIC warns that personal information entered into some AI systems may be difficult to track or control and potentially impossible to remove. A professional product intended to handle client files should be able to provide a substantially clearer answer.
Deletion should ideally be addressed in both the product functionality and the contractual documentation.
Identify human access
Encryption does not necessarily mean that no person can access customer information.
Provider personnel may require controlled access for:
- technical support;
- system maintenance;
- security investigations;
- abuse monitoring; or
- legal compliance.
Relevant questions include:
- Which personnel can access customer content?
- In what circumstances is access permitted?
- Is approval required?
- Is access logged?
- Where are those personnel located?
- Are they subject to confidentiality obligations?
- Can the customer restrict or disable support access?
A clear description of controlled access is often more useful than a broad assertion that nobody can view the information.
The assessment should also distinguish access to account information from access to the contents of client files. A provider may apply different controls to each.
Identify the subprocessors
Many AI systems rely on a chain of providers.
The company dealing directly with the practice may use separate providers for:
- cloud infrastructure;
- language models;
- optical character recognition;
- document extraction;
- authentication;
- analytics;
- monitoring; and
- technical support.
These are commonly described as subprocessors.
Obtain the current subprocessor list and identify what each material provider does. Check whether customers will be notified before a significant provider or processing location changes.
ASD’s ACSC identifies third-party services and supply-chain dependency as material AI risks. Its small-business guidance recommends evaluating the vendor’s use of third-party tools, reviewing its data terms and understanding its incident-notification process. Its separate AI data security guidance addresses the protection of data throughout the AI lifecycle and across the wider data supply chain.
A subprocessor list without a description of each provider’s role is better than nothing, but it may still require follow-up.
Move past “enterprise-grade security”
“Enterprise-grade security” is a description, not a control.
Depending on the proposed use, ask about:
- encryption in transit and at rest;
- multi-factor authentication;
- individual user accounts;
- role-based permissions;
- separation between customer workspaces;
- controls on sharing and exporting;
- audit and activity logs;
- vulnerability management;
- independent penetration testing;
- backup and recovery arrangements; and
- recognised security certifications.
ASD’s ACSC recommends measures including encryption, role-based access controls, vendor security assessment, transparent data-handling policies and recognised security frameworks.
Certifications can provide useful evidence. Their scope still matters.
A certification may cover the provider’s corporate systems but not the product being assessed. A recently introduced AI feature may also sit partly outside the certified environment.
Ask which products, regions, systems and operations are included.
Internal security features are equally important. A technically secure platform will not compensate for shared logins, unrestricted matter access or accounts that remain active after staff leave.
Understand the incident process before an incident
No credible technology provider can guarantee that a security incident will never occur.
It should be able to explain what will happen if one does.
Review:
- how and when customers will be notified;
- what information the notice will contain;
- whether relevant logs will be preserved;
- how affected information and users will be identified;
- what investigation support will be provided;
- how the provider will assist with remediation; and
- how responsibility for regulatory and client notifications is allocated.
ASD’s ACSC recommends understanding a vendor’s cyber incident notification process and incident-response mechanisms before adopting an AI product. It also recommends clear contractual provisions dealing with data protection and breach notification.
The practice should also know who receives the vendor’s notice internally. A strong contractual process is of limited use if the notification is sent to an unattended inbox.
Part 4: Can its use be controlled inside the practice?
Define approved products and uses
Vendor due diligence covers only one side of the arrangement.
The practice also needs a workable internal position on:
- which AI products are approved;
- which tasks each product may perform;
- what information may be entered;
- what uses are prohibited;
- when client explanation and consent must be confirmed;
- who can approve a new product or use case;
- how outputs must be reviewed; and
- how mistakes or incidents are reported.
This does not need to become a large governance program.
For many practices, a short policy, an approved-product register and a defined consent process will provide a sensible starting point.
The controls should reflect how the products are actually used. A policy that prohibits conduct while giving the practice no way to identify whether it is occurring will have limited practical value.
Make access visible and manageable
Useful administrative features may include:
- individual accounts;
- role-based access;
- matter-level permissions;
- records of uploads and exports;
- deletion logs;
- centralised settings;
- rapid account suspension; and
- clear staff offboarding.
Without these controls, it may be difficult to establish which client information entered the system, who uploaded it and what happened afterwards.
Not every small practice needs complex enterprise administration. It should still be possible to know who has access and to remove that access when it is no longer needed.
Review changes to the product
AI products change quickly.
A provider may change:
- the underlying model;
- default settings;
- retention periods;
- subprocessors;
- processing locations;
- product features; or
- contractual terms.
The OAIC expressly warns against treating AI due diligence as a “set and forget” exercise. It recommends regular review of the product, staff training and monitoring throughout the product lifecycle.
A review every six or twelve months may be proportionate for many products. An earlier review may be needed after a material feature, provider or contractual change.
The practice should also decide who receives product-change notices and who is responsible for assessing them.
Keep a short approval record
Due diligence does not need to result in a 50-page procurement report.
A short internal record could capture:
- the exact product and subscription;
- the approved use case;
- the information involved;
- the client explanation and consent process;
- the provider documents reviewed;
- storage and processing locations;
- retention and deletion arrangements;
- model-training and human-access terms;
- material subprocessors;
- relevant security controls and settings;
- restrictions placed on use;
- the person who approved it; and
- the next review date.
That record becomes useful when a provider launches a new feature, changes its terms or moves to another underlying model.
It also means the reasoning does not exist only in the memory of the person who happened to research the product.
Answers that need a follow-up question
None of the following statements automatically makes a product unsuitable:
- “Your information is private.”
- “We use industry-leading security.”
- “We do not sell customer data.”
- “Your data is not used for training.”
- “Customer information is encrypted.”
- “We are Australian hosted.”
- “Information is deleted when no longer required.”
- “We comply with all applicable privacy laws.”
They may all be accurate.
They are also incomplete.
A provider should be able to explain:
- which information;
- which system;
- which people;
- which purposes;
- which locations;
- which retention periods; and
- which contractual commitments.
The object is not to catch the provider out. It is to understand the product well enough to make a professional decision about its use.
The one-page checklist
Before an RMA enters client personal details into an AI platform or system, the practice should be able to answer:
- What exact task is the system performing?
- Does that task require the proposed information?
- What could happen if the system produces an incomplete or inaccurate result?
- Has the use been explained to the client?
- Has written client consent been obtained in accordance with OMARA’s published position?
- Which exact product, plan and settings are being used?
- What information enters, leaves and is generated by the system?
- Where is that information stored and processed?
- Is it used for training, evaluation, improvement or human review?
- Which vendor personnel and subprocessors can access it?
- How long is it retained, and what does deletion remove?
- Which security, user-access and audit controls apply?
- What happens if there is a security incident?
- How will the practice supervise, document and periodically review the use?
For immigration law practices, the same product checklist is useful. The professional analysis should be undertaken under the legal profession framework applying to the practitioner rather than by treating OMARA’s guidance as directly governing the lawyer.
The practical position
OMARA’s 5 March 2026 guidance provides a clear regulatory starting point for RMAs.
The RMA remains responsible for immigration assistance provided with the help of AI. The Code continues to apply. OMARA’s consumer information says the proposed use should be explained in advance and that written consent is needed before an RMA enters the client’s personal details into an AI platform or system.
From there, the practice still needs to assess the proposed use, the product and its own internal controls.
Consent addresses what the client has been told and agreed to.
Product due diligence addresses whether the particular system is sufficiently secure, transparent and appropriate.
Internal governance addresses what happens when the system is used across a real practice by real people.
Where a provider cannot clearly explain data location, retention, model use, human access, subprocessors, deletion and incident response, identifiable client information should not be uploaded until the outstanding questions have been resolved.
That is not an argument against adopting AI.
It is what allows a professional practice to adopt it with confidence.
A note from VisaQA
VisaQA is itself developing an AI-enabled product for migration practices.
The questions in this article are therefore questions we believe vendors, including VisaQA, should be prepared to answer clearly and in writing.
That includes direct answers about data location, retention, model use, human access, subprocessors, deletion, security controls and incident response. Migration practices should not have to rely on broad assurances when client information is involved.
VisaQA is currently in private development for Australian migration practices.