A tool and database for each: more scattered than in the days of Excel files

Why is your company more scattered when everyone saves time with the AI tool they use?

Your colleague saves time with the quoting tool they use. You still spend your time matching its data to the agreements from clients. To answer a shared question, somebody has to gather information that nobody keeps together. That is where the company becomes scattered. Let us take a question from management: « which quotes can we count towards the sales for this month? » One person uses their tool to track the proposals that have been sent. Another uses theirs to keep the agreements that have been received. Before deciding, you still have to check the answers together. Each person can have an accurate answer for their part of the work. Yet a colleague has to find the matches between the records. And that colleague has to ask for clarification when the information does not identify the same deal.

The individual gain does not establish that of the company. Choose a question that requires answers from several of the people involved. Ask for the evaluation of the tool to include reconciliation time alongside the time that its user saves. Does the shared answer still require you to review the records individually? Decide who will handle it and when the work must be finished. It is verified information that the pending decision requires. Then assess the integration of artificial intelligence into working practices through to that shared answer. Count the work actually completed. Take account of the person who picks up the information after its production, and the time they spend on it. Take account of that work even if the colleague’s tool shows nothing of it.

Where are the tools hosted when hosting for them is included with the service?

When hosting is included, the tool runs on the servers of the service chosen to build and publish it. The same package can provide the database for it. The person who creates the application can therefore make it accessible through a web address. They can do so without asking their company to buy the server. The equipment is already there. To understand what that convenience changes, let us follow the progress of a quoting tool. The process starts with the request that is sent to an agent. It continues through to the launch online.

1. Have the code produced. The person describes the form that they want and the calculation that they expect. The model used by the coding agent produces code from that request. You still have to check the result. A screen that displays does not guarantee the accuracy of a quote calculation.
2. Connect the application to its database. To retrieve a quote after the page has been closed, the application has to save it. Does the service have a database to offer as well? That setup can take place in the same environment. It can take place without a separate order for the storage software.
3. Examine the hosting offered. The included package provides a location. You still have to examine its suitability for the data. The CNIL (2024) recommends a prior risk analysis, governance and internal rules for use; depending on the deployment, those rules may prohibit sending personal or confidential data, and on-site hosting is presented as preferable for sensitive data.
4. Publish the tool online. Publication makes the application available at its address for use. Security accompanies this process: the guide from ANSSI (2024) covers generative AI systems from design and training through to production deployment and use; it explicitly excludes personal data protection as well as the quality or performance of the domain model.

At HENUSSE, our coding is done with agents every day. We benefit from that convenience too. Integrating artificial intelligence into working practices therefore involves a decision on equipment from the choice of creation service. The company can already have a hosted tool before its hosting has been discussed collectively.

Where can the data reside when everyone builds a database of their own?

When everyone builds a database of their own, the data resides in sets that are separate. Each application defines its fields and the meaning of its statuses. A spreadsheet on a shared drive brings the rows together with the same set of columns. That does not guarantee everyone will fill them in correctly. Two quoting applications, however, can have different ways of organizing the same information. Consider the status “validated”. In a database, it can mean that management has approved the proposed price. In the other, it can mean that the client has accepted the quote. It is the same word that has two different commercial meanings.

Who can still read the data without using the tool that produced it?

A colleague can read the data without the tool that produced it. They need an authorized way to retrieve it, in a format that they can open. And they need explanations that are sufficient to understand each of the rows. Another compatible spreadsheet application allows you to copy and open the Excel file. But the data can remain in a database that is accessible only through its application. Sharing its address then leaves the colleague dependent on the screens and their options for reading the data. The “export” button therefore deserves a try. The resulting file can contain the rows displayed on the screen, without the information needed to use them elsewhere.

An export does not establish that the data is reusable. Does a quote in it have a number for the client? The person who receives the file has to be able to find the corresponding name. They have to be able to do so without opening each record in the original application to match it manually. Check the data that the colleague needs for their work, within the limits of their access rights. That does not imply full database access for everyone, or visibility of all the information.

Ask for the data to be read outside the tool. Choose a quote that you know the contents of. Ask an authorized colleague to find it in the export. With the file received and the accompanying explanations, they must be able to read the quote amount and find the client’s name. Keep the usual screen closed. Each necessary return to the application reveals information missing from the material that was shared. The missing information can be a match between two files, for example. Or it can be an indication as simple as the currency of the amounts. If reading stalls, add to the export or its instructions at the precise point of difficulty. Review the same quote with the colleague until they can answer from the material received. They must be able to answer without your help and without consulting the application.

Who has knowledge of the tools’ existence before their creator leaves?

The creator may be the only person who knows that a tool exists. That can be the case even when their work feeds into that of their colleagues. Receiving the output of an application gives you no reason to suspect its presence behind the documents shared each week. Their departure can reveal that dependency. Consider one person who uses a small application for the preparation of sales tracking. They send the resulting document to their team, without ever presenting the application itself. Their replacement finds the usual documents within the folders of the company. Nothing indicates to them that a separate tool was used to prepare the documents. Nor does anything indicate to them the name under which to look for the service that hosts it. Does a colleague then find the application’s address in an exchange that they have from the past? The provider account may remain untraceable. It is the email address that was used for registration that is missing. The company then discovers that part of the work depended on that tool. It received the results without knowing of its existence. Its only reference point was the person who had left.

Does building a tool not also allow you to clarify the work?

Yes. Building a quoting tool requires you to clarify the rules that it will apply. Who approves a discount? In which cases should you authorize an exception to the pricing? Consider a quote for which a salesperson wants to retain the old rate. For the tool to accept or block that proposal, a decision has to be made. Can the salesperson act independently, or do they have to obtain a manager’s approval? What is the justification for retaining that price for that client? The design exposes a decision that the instruction to “use the usual terms” could have left open. The consequence is concrete for the person who has to prepare the quote. They now know when they have to ask for the approval.

But the creator can put their own answer into the code without having it approved. The screen then presents their personal interpretation of a practice as a rule of the company that applies. It can even present a provisional choice made to finish the tool as a company rule. A block takes on an official appearance. In our example, a message requires the approval of management to retain an old rate. That message alone does not reveal the origin of the requirement. Is it a commercial decision that is still valid? Is it a precaution that was added during the build? The difference matters to the manager who is then asked for authorization of an exception.

To retain this benefit of clarification, record the rule in a document that can be read without consulting the code. Indicate who has approved it and why. For the old rate, also specify the circumstances that allow you to make an exception. The next case can then be discussed with an explicit basis for discussion. A dated note may suffice. It must allow you to find the original decision. And it must distinguish an approved rule from an assumption that still needs confirmation before the tool is used to prepare quotes. The integration of artificial intelligence into working practices thus gains a concrete basis that it can draw on. Does a manager dispute the block? The discussion can focus on the justification for the approval threshold. And it can result in an acknowledged change to the rule and the application.

What can you do this week so everyone keeps their tool without allowing the databases to become scattered?

This week, open a shared register. Create one entry per tool. Indicate its use and address, then the provider that hosts it. Add the location of its database and the account that provides access to it. Do not include passwords in the document. For each entry, record the people who can retrieve the data and understand it. Specify the conditions for taking over the work of the creator when they leave. Who will be able to take over the provider account, and with what rights? Where can you find the instructions needed to continue the work? Make the unknowns visible. To prepare the section on rules for use, draw on the CNIL (2024), which recommends a prior risk analysis and governance accompanied by internal rules; depending on the deployment, these may prohibit sending personal or confidential data, and on-site hosting is presented as preferable for sensitive data.

If an entry reveals a security gap, the guide from ANSSI (2024) covers the security of a generative AI system from design and training through to production deployment and use; it explicitly excludes personal data protection as well as the quality or performance of the domain model. To choose the first gap that you address, use this operational method. Does a tool that is necessary for the work depend on access held only by its creator? Assign the takeover of it to another person. Is access shared, but the data that you have remains incomprehensible? Have an actual export documented. Enter the name of the person responsible and a deadline for this week in the entry. Check that the designated person can take over the tool or read the export with the available instructions. The time saved is also measured by the work of the colleague who follows.