Private Data and Generative AI: Simple Rules for a Business Team

The employee requests an AI system to shorten a customer message. The message includes a name, an address, and some service-related information. It might be helpful to do this, but first of all, the employee must know what information they are allowed to share. Just copying and pasting might transfer more information than is necessary for the task.

Personal data and Gen AI must be managed together. The application might access the source records, make a request, draft a message, and keep logs. In each case, private details may be involved. The protection of just the text field is not enough to protect the entire process. There must be clear rules for handling data and people who can use them.

This guide explains those concepts in plain English. We will use a draft message feature as an example of how to plan the process. These are not actual customer data or claims about Digitonix results. The goal is to decide what information the feature needs, who will use the draft, and what should happen if data correction or deletion is requested.

List the information the task needs

Describe the task first, and then the data required to do the task. A reminder draft will require the date to be confirmed and the service name. It may not need the entire customer address or all previous notes. Only the data required for the allowed task should be used. Providing extra data just to make things easier can share more information than needed.

Figure out why you include each piece of data. If no one can give reasons, it probably shouldn’t be sent. Keep it simple enough that the employees and the software engineers can understand the rules. A list of what is allowed is simpler than saying "use the customer’s account." The data plan needs to describe the process and not just gather everything from the application.

Understand the full data path

Show where the data travels. For example, the application reads the record, sends a message to the external company, gets a message back, saves it, and displays it for the employee. Logs and previews may also need to be created. Describe it in simple language. The people who build this application need to know what belongs to their application and what doesn’t.

Think about what kind of access to this data the type of people will have. For example, the reviewer must have access to the draft of the document, while the support person will need only the reference and the status of the request. One and the same data can be stored in several places at once, so one screen of access control will not be enough. Be sure to check all the stages of the process before declaring that the process is ready to process the private business data.

Read the provider's current terms

This data will be handled in accordance with the different approaches of AI software. You must find out the policies and the settings related to your selected software and its provider right now. It will depend on the place of storage, duration, access rules, and the provided services. You cannot be sure that one policy is good for another product.

For instance, AWS offers information about the protection of data for Amazon Bedrock. Use the information provided by the provider when reviewing these settings. Make sure to ask the responsible business and technical owners to check the needs before sending any private data. It is helpful to document the decisions made and the people responsible for that once the service or application changes. See data-protection information for Amazon Bedrock for related information.

Use safe samples while building

Sometimes the early stages require sample records, but not necessarily any personal customer details. Use the samples that are allowed with the removal of identification or replacement under the project’s rules. The task must be realistic enough for testing purposes. An example note may have an unclear date or description without any person's account history.

It would be wrong to label a sample as safe merely because one name has been changed. There might be other information that can identify a person or provide private data about businesses. Look at the whole sample and how it will be used. Make sure that there is proper access during development and testing of the project. The goal is to learn from data with a clear data boundary and not to copy production records into any tool that is available.

Keep secrets out of ordinary prompts

Avoid sending access secrets such as passwords and private keys in the regular requests. Prompt is the text or instructions provided to the model. It is not a secure way to keep the access credentials. The application must be able to access its services through proper ways that have the correct access policies.

Teach staff what they must leave out. It is better for you to give examples instead of advising them to be careful. Explain who to ask when a task needs unusual information. It is never allowed to allow the employee to fix the application problems by giving his/her credentials or a long private log in the chat.

Apply access rules before retrieving records

The user has the right only to those data he or she can receive. The application shall manage access rules for the user while he or she uses source data. When the user asks some question to the AI, it doesn’t mean that account restrictions are no longer valid. The lack of button doesn’t affect the user’s permission to read the document.

Consider various possibilities of role changes and memberships. A user who had the opportunity to view the document yesterday may lose this possibility today. Previous connections, drafts and cached results will need proper treatment. Check how the new policy works. It is not enough for the system to store the information that the user could read the source page before.

Remember that answers can contain private data

A draft copy can duplicate information from the source document. So, its access is important too. A summary is not automatically public because it is shorter. Apply the right rules when the application saves, displays, shares, or exports the result. The user needs to know the target audience of the message before doing a supported share or send operation.

Also, consider both the facts and privacy issues. The draft may reveal some information and yet be incorrect about it. Provide right context that will allow a person to check critical statements before sharing or using the draft. Separate draft generation from actions related to the final result. Clear procedures will help the team to see what the tool has done and avoid turning the generated piece of text into an unverified statement of the customer.

Keep logs useful and limited

Logs will help the team in discovering problems. It is not necessary to log all private inputs and complete outputs by default. In many cases, the reference to the request, task state, and results of processing might be enough. Decide which evidence you need for support and limit access to sensitive information. Include this in the data strategy.

Screenshots and support messages need to be reviewed as well. An employee can send a draft message confidentially and ask for assistance. Make sure there is a way to keep such information in the proper audience. Support must be able to investigate an assignment without disclosing entire customer messages to chat rooms. The information flow involves normal human behavior and the settings of the application’s storage.

Plan retention across the whole feature

Retention period means the time information is stored. Drafts, notes, logs, and searches may need different periods. Make sure you agree on the terms with the business and the proper consultants for their specific situation. Document which copy of the information each term applies to. Don’t think that simply deleting a draft from the screen deletes all traces left during processing.

Define the technical process and exceptions. If the removal request is unable to complete, the system requires a trackable state and an owner for the next action. Related services may have their own policies and limits. The business should be able to describe what the application is able to confirm, rather than stating a general policy on removal that the design is not able to check.

Give staff simple working rules

Create a short guideline about the acceptable use. Explain what tool is allowed to use for that purpose, what information can be entered, what the employee should check before proceeding, and what to do if there are problems. Use practical examples and clear language. The technical documentation will be necessary for developers, but the employee needs a simple guideline to follow.

Make a way to ask questions. If a new use case appears, it will require a new type of review instead of a quick decision made on the spot by one employee. Clarify who can change the list of acceptable inputs or activities. Update the staff manual if there is a change of process. The users should not wonder whether the old process applies to the new function or account of another provider.

Prepare a response to mistakes

Mistakes do occur, and the team needs a process for reporting and investigating them. The employee needs to know where to report a problem with the wrong information being sent or displayed somewhere. Save the helpful references and go through the business’s process for dealing with the problem. Do not make the problem worse by sending the sensitive information in an open support request.

Decide who is responsible for the issue. The person will find out what went wrong, what services and/or records have been affected, and what actions could be taken further. The collaboration of technical and business departments may be required. Having a clear response plan does not mean that there would not be mistakes; but, it means that the company will take actions based on evidence, not just assumptions about the data flow.

Test the boundaries and keep them current

Test allowed and restricted access by using safe records under the project’s agreed process. Test altered access rules, absence of source, outdated drafts, and denied request. Identify the information available to the user and evidence stored for the support. One positive response from the AI does not mean that the privacy limits are functioning throughout the feature.

Review important changes to providers, models, application inputs, and source collections. Be certain of ownership of access, retention, logs, and employee policies after launch. This feature may evolve, but its data scope must not evolve quietly behind the scenes. An effective first release has a clear mission and clear plan about the information involved.

How Digitonix can help

The solutions and services provided by Digitonix concerning AI and cybersecurity are right contexts to mention an AI feature's path of the data. Mention the task, safe examples, account roles, provider options, and data retention policies. Make sure that there are clear limits, access checks, evidence of usefulness, and owners for any changes. Check actual needs and process before use of private records in the process. See AI solutions for related information.

For an application developed in Python and AWS, one needs an approach to the usage of services and business needs. With the help of Digitonix contact, one should find out what kind of information is allowed and what is the procedure for each draft. The aim is a small feature with clear controls and evidence, not a general assumption that artificial intelligence makes all information secure.

Frequently asked questions

Is a shorter AI summary automatically safe to share?

No. It might include private information extracted from the first source. One needs to look through the content and target audience to set up right restrictions when working with the text in question and exporting it. Even when the text has been shortened, it will be hard for you to exclude the privacy-related risks altogether. The app should make the allowed sharing step clear.

Can we assume every AI tool has the same data policy?

No. Check the chosen software, the terms offered by the vendor, your account and extra features. Different vendors act in different ways when providing services. Make a note of the selection that has been made, taking into account the owner. You should avoid applying an outdated or a general policy of another product until you make sure that it fits the situation.

Should logs store every customer prompt?

Pick out useful evidence for the task at hand and supporting process. Useful references and states may be good enough for some tests. For a check where sensitive details are required, make sure to keep it restricted and add to retention policy.

Does removing a draft from the screen remove all copies?

Not always, though. Information could be held in other logs or preview services based on their settings and policies. Trace down the copies and decide how long each of them should persist. There must be a record that shows whether deletion worked and someone responsible for the exceptions. Do not assume that the changes on the screen equal the deletion of information.

What should we prepare before adding AI to a private workflow?

Supply the allowed action, necessary fields, account roles, secure samples, provider options, and how long each copy should be kept. Mention support and change owners. Provide the full path of the information and useful boundaries. The above helps scope a controllable first feature that the business can use to judge the build and keep it beyond the release point.