Available Data, Storage and Protection

Which company and request data is available within Bierens’ systems, which information is relevant for the initial assessment of a case, and how is this data stored and protected?

I interviewed Laurens van der Lof on 2 September 2026 to explore available company information. I subsequently explored KVK and internal company/credit-score information and discussed API access with a developer. This report combines those activities with the internship project proposal and describes remaining questions explicitly. It is not an internal systems audit.

Incoming requests may include a contact name, company name, email address, telephone number and a free-text description of the matter. Sales uses these details to understand the request and determine whether more information is needed. Exact mandatory form fields and the backend data model still require confirmation.

During my research, I investigated how Bierens can retrieve reliable company information for the initial Sales assessment process. This included exploring the KVK company register, internal credit information and the possibilities of connecting these sources to the n8n workflow.

An earlier experiment with the custom GPT showed that publicly available company information is not always reliable. During testing with 20 Dutch companies, the GPT produced four classifications that did not match the expected Sales results. Some problems occurred because inactive companies were not correctly identified or important financial information was missing.

These findings showed the importance of using verified company information instead of relying only on AI research and public websites.

KVK Integration

I have now implemented KVK API connections in the n8n prototype. The workflow can use KVK information to verify company details and check whether a company is registered as active or inactive.

During initial testing, the KVK integration successfully identified an inactive company. This demonstrated how retrieving information from a company register can help address one of the problems found during custom GPT testing.

However, the integration is still part of a prototype. Further testing is needed to confirm the accuracy of company matching, the available API fields, error handling and how the workflow performs with different companies.

Internal Company and Credit Information

Bierens also has access to company and credit information that could support the Sales assessment process. Relevant information may include credit scores, financial indicators and other company attributes.

I investigated how this information could be used in the automated workflow. However, the credit-information API has not yet been integrated into n8n. Access permissions, available fields, licensing and costs still need to be confirmed before implementation.

Credit information should only be used when it comes from an approved source. If a credit score is unavailable, the workflow should mark it as unknown rather than generating an estimate.

Data Reliability

Even when company information comes from an API, it is important to check whether the correct company has been identified. Companies may have similar names, and information can become outdated.

For this reason, the workflow should record the company registration number, information source and retrieval date whenever possible.

If company information is missing or conflicting, the workflow should clearly indicate this and forward uncertain results to Sales for review instead of automatically making a final decision.

Findings

The KVK integration is an important improvement in the n8n prototype because it allows company information to be checked against an official registration source.

The initial tests demonstrate that this approach can help identify inactive companies more reliably than public-web research alone. However, the overall improvement in classification accuracy has not yet been measured.

The next steps are to test the KVK integration with more companies; investigate access to the credit-information API and determine which company attributes are most useful for the Sales assessment process.

Based on the current project description, a credit statement can be requested, and a saved copy may be used afterward. This should be treated as a reported workflow, not a verified storage architecture. I still need to confirm which internal system generates the statement, where the copy is stored, who may access it, whether it is refreshed, and how long it is retained.

A saved credit statement is a snapshot. It may become outdated. An automated workflow should therefore record the statement date and source, avoid silently presenting old data as current, and request an updated statement when the business process requires one.

During my research, I investigated how Bierens stores internal information and manages access to external AI services. This helped me understand which technical and security requirements should be considered when developing the automated Sales assessment system.

The n8n automation environment is hosted on Bierens' own servers using Docker. Docker allows applications to run in containers, making them easier to deploy, maintain and manage. The internal database is also hosted on-site within Bierens' building, rather than through an external cloud provider. This gives Bierens direct control over the infrastructure used to store and process internal information.

However, local hosting does not automatically mean that all information remains within Bierens' infrastructure. The n8n workflow may connect to external services, such as the KVK API or an AI provider. When these services are used, certain information may be transferred outside Bierens' internal environment. Therefore, the data shared with each service and its processing location must be considered.

Bierens also has security measures in place to control the use of external AI technology. Employees cannot freely install, download or connect external AI tools without administrative approval. If an employee needs access to a particular service, an access request must be submitted to an administrator, who decides whether the service may be used.

Certain AI services, including DeepSeek and other Chinese AI services, are blocked within the Bierens environment. These restrictions help Bierens control which external AI providers can be used and reduce the risks associated with unapproved technology.

However, administrative approval does not automatically guarantee that an external service meets all privacy and security requirements. Important factors include where information is processed, how long it is stored, who can access it and whether personal or confidential information is shared with third parties.

Findings

This investigation established that Bierens uses locally hosted infrastructure for n8n and its internal database and applies administrative restrictions to external AI services.

These findings are important for the proposed Sales assessment system because they show that the workflow can be developed within Bierens' existing infrastructure. However, every external connection must still be evaluated separately to ensure that information is handled according to Bierens' security requirements.

Further investigation is needed to confirm the detailed access permissions, logging configuration, backup arrangements and data retention policies. These aspects should be discussed with the development team and relevant security stakeholders before the system is used with sensitive Sales information.

Incoming Sales requests can contain personal information, including names, email addresses, telephone numbers and case descriptions. They may also contain confidential company and financial information. Because the proposed AI solution will process this information, privacy and data protection are important parts of the project.

Bierens has implemented restrictions on the use of external AI tools. Employees are not allowed to freely download, install or connect to AI services without permission from an administrator. When an employee wants to use an external AI service, they must submit an access request. The administrator reviews the request and decides whether the service can be used.

Some AI services, such as DeepSeek and other Chinese AI services, are blocked. This shows that Bierens applies restrictions to the use of certain external AI providers.

Another relevant measure is that the internal database and n8n environment are hosted on Bierens' own infrastructure. This gives Bierens direct control over the servers used for these systems.

However, local hosting and administrative approval do not remove every privacy risk. If an approved AI service processes data externally, information may still be transferred outside Bierens' infrastructure.

For this reason, the proposed solution should follow GDPR principles such as data minimisation, purpose limitation and appropriate security measures. Only the information required for a particular AI task should be shared, and external services should only be used when approved by Bierens.

These findings show that Bierens already has technical and organisational restrictions in place to control the use of external AI services. Further investigation is needed to understand the specific data retention policies and how approved external AI providers process information.

Access control

Only authorised Sales and technical users should access request and company data. API credentials should be stored in approved secrets/credential storage, not embedded in workflow code.

Data minimisation

Only send fields needed for a specific task. A summarisation model may not need a full credit statement or all contact details.

External AI services

Before sending information to a hosted GPT or other LLM, verify provider agreements, retention/training settings, data location and whether the transfer is approved. Local n8n alone does not prevent an external data transfer.

Logging and retention

Avoid storing full case descriptions, credentials and sensitive responses unnecessarily in n8n execution logs. Set approved retention and deletion rules for requests, logs and saved statements.

Accuracy and human review

Keep source references, timestamps and error flags. Do not automatically reject or approve a case solely because a model guessed a company attribute.

Testing

Use fictional or anonymised requests during development unless real data use is explicitly approved.

The investigation shows that Sales assessment can draw on incoming request details and company information such as registration status, employee count and credit information. The KVK and internal credit-score resources are particularly relevant because open-web company information has shown reliability problems in the GPT experiment. These data points can support Sales, but their actual availability, quality and permitted use depend on the specific system and access rights.

The storage and protection part of SQ2 has been partially answered. During my research, I established that n8n is hosted in Docker on Bierens' own servers and that the internal database is located within Bierens' building. I also identified security restrictions requiring administrator approval before employees can use external AI services, with certain providers blocked.

These findings show how Bierens controls its internal infrastructure and access to external AI tools. However, further investigation is needed into data retention, logging, backup arrangements and how approved external AI services process information.