How to Transfer Data Securely for AI Training

Security starts before the transfer

The safest data is the data you never send. Before thinking about transfer methods, make sure the scope is tight. Your company should decide exactly which repositories, workspaces, tables or folders are included, and anything outside that list should stay where it is.

Order matters too. In a Momentra partnership, an NDA covering confidentiality, permitted use, retention and security is signed before any sample is reviewed. Full transfer happens only after the purchase proposal and contract are agreed. That sequence means nobody is handling your data before the rules are written down.

De-identify before data leaves your control

Wherever possible, sensitive information should be removed or replaced as early as practical, so that what travels has already been reduced. Professional anonymization with purpose-built tools is used to detect, remove or replace sensitive information before further use. Typical targets include:

• Personal information such as names, emails, phone numbers, addresses and government ID numbers.
• Credentials and secrets: API keys, passwords, tokens, private keys and connection strings, including those buried in old commits.
• Customer and commercial details such as account numbers, pricing, contract values and client names where they are out of scope.
• Internal infrastructure details such as hostnames, IP addresses and internal URLs.

Choosing a transfer method

The right method depends on volume and on your own IT policies, but some principles apply across the board. Data should be encrypted both in transit and at rest. Access should be limited to named people for a limited time. Email attachments, public file-sharing links and personal accounts are not appropriate for this kind of material.

Common approaches include secure file transfer services with expiring, access-controlled links, cloud storage buckets with tightly scoped credentials, or encrypted archives where the decryption key is shared through a separate channel. Whichever is used, record it in the agreement so both sides know what was promised.

Large transfers deserve a little extra planning. Splitting data into clearly labelled parts, transferring them in an agreed order and confirming each part on arrival makes it easier to resume after an interruption and to prove that every part was received intact. If your IT team has a preferred tool or policy, raise it early so the method can fit your existing controls.

Access control on both sides

On your side, limit who can prepare and export the data. A small, named group with a clear brief is better than giving broad admin access to a contractor. Use a dedicated export account where your systems allow it, and remove that access once the job is done.

On the receiving side, the agreement should state who can access the data, for what purposes, and under what security conditions. Ask how access is logged and how long logs are kept. These are reasonable questions, and a serious partner should be comfortable answering them.

Think about people as well as systems. Staff who help with the export should know what is in scope, what is not, and who to ask if they find something unexpected, such as a folder of customer documents inside a code repository. A short written brief avoids well-meaning mistakes.

Verify what was sent

Keep a manifest: a list of every file or dataset transferred, its size and ideally a checksum, which is a short fingerprint that proves the file was not altered. Both sides should be able to confirm the manifest matches what arrived. This protects you if questions come up later about what was or was not included.

It is also wise to spot-check the de-identified output before final transfer. Open a sample of files and search for obvious things like your own domain name, a known customer name or the word password. Automated tools are good, but a human review of samples catches surprises.

Common mistakes to avoid

Most problems with data transfers come from haste or informality rather than sophisticated attacks. These are the mistakes worth watching for.

• Sending a quick sample by email before the NDA is signed, because someone asked for it informally.
• Exporting a whole workspace or database when only part of it was agreed, and relying on the other side to ignore the rest.
• Sharing the password for an encrypted archive in the same message as the archive itself.
• Leaving a cloud storage link or export account active long after the transfer is complete.
• Forgetting that old commits, attachments and file version history can contain material removed from the current version.
• Not keeping a record of what was sent, which makes later questions hard to answer.

After the transfer

Security does not end on delivery. Clean up temporary copies, staging buckets and export accounts on your side. Make sure the agreement covers retention, meaning how long data may be kept and what happens at the end, and confirm how deletion or return will be evidenced if that is part of the terms.

• Delete local staging copies and revoke temporary credentials.
• Rotate any secrets that were ever present in the source data, even if they were removed.
• File the manifest, the signed agreement and records of who approved the transfer.
• Diarise any retention or deletion dates set in the agreement.