# enter 2.0 > Senior consultancy based in Navarra for practical AI, data, dashboards, document automation, operational tools, Fractional IT Director and IT governance. Local focus and extensive experience in the non-profit sector; work is possible with organisations in any territory. Anonymised cases by default, no published prices, and a human reply to every enquiry. --- ## Practical AI, governed data and information systems > enter 2.0 helps organisations, especially in the non-profit sector, turn scattered information into systems, indicators, dashboards, automations and safe AI workflows. - URL: https://www.enter20.com/en/ - Español: https://www.enter20.com/ - Updated: 9 November 2026 - enter 2.0 — Practical AI, governed data, dashboards, automation and information systems for organisations that need to make better decisions. enter 2.0 helps foundations, associations, SMEs and public-interest teams turn scattered information into reliable systems, useful indicators, dashboards, automations and controlled AI workflows. Based in Navarra, with a close focus on the local area. Given the nature of analysis, data and digital work, it can also work with organisations in any territory when the context allows. ### The information exists, but it is trapped in spreadsheets, emails, PDFs and informal routines. Many organisations already have the data they need. The problem is that it is duplicated, incomplete or spread across applications, documents, folders and team memory. AI can help, but only when the process, the data model, the permissions, the quality of the source and the decision to be improved are all understood. There is extensive experience in the non-profit sector: foundations, associations, social projects, teams with limited resources and real obligations around management, justification and accountability. ### From diagnostic to something usable The work usually ends in a roadmap, a data model, a dashboard, an automation, an internal tool or a safer way of using AI in real operations. - [AI and data diagnostic](https://www.enter20.com/en/services/ai-data-diagnostic/): Identifies where AI can bring real value and where processes, data and permissions first need to be put in order. - [Data, indicators and dashboards](https://www.enter20.com/en/services/data-indicators-dashboards/): Turns scattered spreadsheets, forms and applications into reliable indicators for management and accountability. - [Bespoke operational tools](https://www.enter20.com/en/services/bespoke-operational-tools/): Small internal applications for when Excel, forms and disconnected SaaS no longer support the daily work. - [Fractional IT Director](https://www.enter20.com/en/services/fractional-it-director/): A senior part-time IT function for organisations that are too small to maintain IT leadership of their own. - [Document and data automation](https://www.enter20.com/en/services/document-data-automation/): Processes PDFs, spreadsheets, surveys and repetitive exports with scripts, OCR, rules and human review. - [IT governance, continuity and operations](https://www.enter20.com/en/services/it-governance-continuity/): Clarifies who controls the systems, where the data lives, how access is protected and what happens if something fails. ### Lab: Don't take our word for it: try it Interactive mini-apps that show how the solutions work, with fictional data and the real status of each one: production, pilot, prototype or design. - [Invoice and payslip inbox with evidence](https://www.enter20.com/en/lab/facturas/) — Pilot: Upload PDFs: data extracted with its evidence, duplicates detected, payslips matched against the bank. - [Management cockpit](https://www.enter20.com/en/lab/cockpit/) — Production: Cross-department matters with an owner, a next step and a committed date. Each area sees its own. - [Dashboard with a decision simulator](https://www.enter20.com/en/lab/escenarios/) — Prototype: Indicators by stage and «Se decide» (it gets decided) switches: which indicators will not arrive on time if a decision is put off. - [Tender and grant radar](https://www.enter20.com/en/lab/licitaciones/) — Prototype: PDF of the call → AI-drafted summary sheet reviewed by people → blind vote → traceable decision. - [ENTERBOX: the AI goes to the documents](https://www.enter20.com/en/lab/caja-documental/) — Pilot: A device in the office turns documents into searchable information, with local processing and the sources in view. - [Organisational memory: the knowledge stays in the company](https://www.enter20.com/en/lab/memoria-organizativa/) — Design: Reviewed definitions, procedures and decisions in the company's own files, ready for a change of AI tool. ### Applied experience in platforms, data, automation and IT governance - [Modular operations platform for a foundation](https://www.enter20.com/en/work/foundation-operations-platform/): Design of an internal platform to organise people, projects, modules, permissions and operational reporting without exposing sensitive data. - [Indicators and dashboards for social monitoring](https://www.enter20.com/en/work/social-impact-dashboards/): Structuring of data and indicators so that foundations and associations can better manage, report on and explain their impact. - [Survey pipeline and qualitative analysis](https://www.enter20.com/en/work/survey-qualitative-analysis/): Transformation of survey exports into reviewable analytical outputs with Python, pandas, Excel and human judgement. - [Document automation with Python and human review](https://www.enter20.com/en/work/python-document-automation/): Workflows to extract text, classify documents and generate structured indexes from administrative PDFs. ### AI as a working layer, not a slogan AI is used to speed up analysis, documentation, classification, prototyping, data extraction, drafting and decision support. Lasting value comes from combining it with well-defined data, clear processes, proportionate security and human review. In some cases the solution will be AI. In others it will be a database, an internal screen, a dashboard, an automation script or a governance rule that prevents errors. > AI proposes; a person decides. ### Notes for deciding with better judgement - [Organisational memory: keeping knowledge in the company when the AI tool changes](https://www.enter20.com/en/blog/organisational-memory-keep-knowledge-when-changing-ai-tools/) (2026-11-09): AI assistants need context, and that context is usually built inside a vendor's tool. Curating it as the organisation's own knowledge cards, with sources, an owner and a review date, makes it reviewable and portable. - [Working with AI assistants without losing the thread: rules and memory in the repository](https://www.enter20.com/en/blog/working-with-ai-assistants-rules-memory-in-repository/) (2026-10-23): If a project's context lives in a tool's chat, it is lost when the tool is closed. If it lives in the repository, any assistant or person can carry on from where the previous one left off. - [Layered security for small internal tools: identity at the edge and failing closed](https://www.enter20.com/en/blog/layered-security-internal-tools-identity-at-edge-fail-closed/) (2026-10-06): An internal tool does not need a VPN or an exposed server. It needs identity before anything can be reached, a service that fails closed when configuration is missing, and tunnels instead of open ports. - [From PDF to reviewed data: fingerprint, evidence and review queue](https://www.enter20.com/en/blog/from-pdf-to-reviewed-data-fingerprint-evidence-review-queue/) (2026-09-18): Extracting data from invoices, payslips or calls for proposals is easy to promise and hard to make reliable. Reliability comes from the document's fingerprint, the evidence kept alongside each data point and a review process that does not get in the way. - [A backup is only as good as its restore](https://www.enter20.com/en/blog/backup-only-as-good-as-its-restore/) (2026-08-31): The backup log can say ‘successful’ and the restore can still fail. Layered backups, test restores and written decisions are what keep continuity in place. ### Want to know where to start? A short diagnostic helps put opportunities, risks and priorities in order before you buy tools or open a large project. Contact: [contacta@enter20.com](https://www.enter20.commailto:contacta@enter20.com) · [Contact form](https://www.enter20.com/en/contact/) · [Diagnostic questionnaire](https://evaluo.enter20.com) --- ## AI, data, dashboards and operational systems services > AI and data diagnostic, dashboards, operational tools, Fractional IT Director, document automation and IT governance services. - URL: https://www.enter20.com/en/services/ - Español: https://www.enter20.com/servicios/ - enter 2.0 — Practical AI, governed data, dashboards, automation and information systems for organisations that need to make better decisions. enter 2.0 combines diagnostic, data, technology, IT leadership and governance to solve specific operational problems, without selling AI as magic or software as an end in itself. - [AI and data diagnostic](https://www.enter20.com/en/services/ai-data-diagnostic/): Identifies where AI can bring real value and where processes, data and permissions first need to be put in order. - [Data, indicators and dashboards](https://www.enter20.com/en/services/data-indicators-dashboards/): Turns scattered spreadsheets, forms and applications into reliable indicators for management and accountability. - [Bespoke operational tools](https://www.enter20.com/en/services/bespoke-operational-tools/): Small internal applications for when Excel, forms and disconnected SaaS no longer support the daily work. - [Fractional IT Director](https://www.enter20.com/en/services/fractional-it-director/): A senior part-time IT function for organisations that are too small to maintain IT leadership of their own. - [Document and data automation](https://www.enter20.com/en/services/document-data-automation/): Processes PDFs, spreadsheets, surveys and repetitive exports with scripts, OCR, rules and human review. - [IT governance, continuity and operations](https://www.enter20.com/en/services/it-governance-continuity/): Clarifies who controls the systems, where the data lives, how access is protected and what happens if something fails. ### Understand first, then build Not every problem needs a new application. Sometimes it is enough to define indicators, automate an extraction, fix permissions or document a critical process. The service is adjusted to the organisation's starting point: a diagnostic, a prototype, improvement of an existing system, a specific automation or IT governance support. --- ## AI and data diagnostic > Identifies where AI can bring real value and where processes, data and permissions first need to be put in order. - URL: https://www.enter20.com/en/services/ai-data-diagnostic/ - Español: https://www.enter20.com/servicios/diagnostico-ia-datos/ - enter 2.0 — Practical AI, governed data, dashboards, automation and information systems for organisations that need to make better decisions. For organisations that want to use AI without buying tools blindly. The diagnostic reviews processes, data, documents, risks, security, reporting and internal capacity before proposing automations or new systems. ### What can remain after the work - A map of critical processes and information sources. - Prioritisation of AI use cases by value, risk and effort. - Recommendations on data, security, training and governance. - A practical roadmap with possible prototypes and pending decisions. ### Technical and operational proof - Use of AI to support analysis, documentation, classification, prototyping and review. - Experience in data models, operational platforms, dashboards and document automation. - The judgement to tell an AI problem from a data problem and from a process problem. ### Anonymised examples - [Indicators and dashboards for social monitoring](https://www.enter20.com/en/work/social-impact-dashboards/): Structuring of data and indicators so that foundations and associations can better manage, report on and explain their impact. ### Related articles - [Organisational memory: keeping knowledge in the company when the AI tool changes](https://www.enter20.com/en/blog/organisational-memory-keep-knowledge-when-changing-ai-tools/) (2026-11-09): AI assistants need context, and that context is usually built inside a vendor's tool. Curating it as the organisation's own knowledge cards, with sources, an owner and a review date, makes it reviewable and portable. - [Working with AI assistants without losing the thread: rules and memory in the repository](https://www.enter20.com/en/blog/working-with-ai-assistants-rules-memory-in-repository/) (2026-10-23): If a project's context lives in a tool's chat, it is lost when the tool is closed. If it lives in the repository, any assistant or person can carry on from where the previous one left off. - [AI proposes, a person decides: how to inventory AI use across your tools](https://www.enter20.com/en/blog/ai-proposes-a-person-decides-inventory-ai-use/) (2026-07-26): Before debating which model to use, it is worth knowing, for each tool, what the AI does, what it never does, where it runs and who reviews its output. - [From cost savings to irrelevance: the danger of automating without redesigning your processes](https://www.enter20.com/en/blog/danger-of-automating-without-redesigning-processes/) (2026-07-08): Automating inefficient tasks moves the disorder onto a faster platform. Real value comes from redesigning the process architecture. - [Why AI projects fail when the data model is not understood](https://www.enter20.com/en/blog/why-ai-projects-fail-without-understanding-data-model/) (2026-06-23): AI can speed up work, but on its own it does not fix ambiguous data, blurred responsibilities or poorly defined processes. - [What an AI adoption diagnostic should include before you buy tools](https://www.enter20.com/en/blog/what-ai-adoption-diagnostic-should-include-before-buying-tools/) (2025-12-18): A serious diagnostic separates wishes, processes, data, risks, people and decisions before any vendors or licences are chosen. - [How to use AI safely in organisations that handle sensitive documents](https://www.enter20.com/en/blog/using-ai-safely-with-sensitive-documents/) (2025-09-19): Using AI safely with documents depends on classification, data minimisation, human review, contracts, records and local alternatives when the risk demands them. ### Does this fit your situation? Take our diagnostic questionnaire to receive a detailed first reading of your case. Contact: [contacta@enter20.com](https://www.enter20.commailto:contacta@enter20.com) · [Contact form](https://www.enter20.com/en/contact/) · [Diagnostic questionnaire](https://evaluo.enter20.com) --- ## Data, indicators and dashboards > Turns scattered spreadsheets, forms and applications into reliable indicators for management and accountability. - URL: https://www.enter20.com/en/services/data-indicators-dashboards/ - Español: https://www.enter20.com/servicios/datos-indicadores-dashboards/ - enter 2.0 — Practical AI, governed data, dashboards, automation and information systems for organisations that need to make better decisions. Design of data structures, indicators, reporting views and dashboards so that an organisation can explain what it does, what results it achieves and what decisions it needs to take. ### What can remain after the work - Definition of indicators and a data dictionary. - Maintainable data models and reporting views. - Internal or public dashboards with quality and update criteria. - Review routines so that the dashboard is not a frozen snapshot. ### Technical and operational proof - Work with master data, social reporting, operational dashboards and visualisation. - Experience with Supabase/PostgreSQL, React, Recharts, R, Shiny, spreadsheets and ETL processes. - A focus on useful indicators, not just attractive charts. ### Anonymised examples - [Modular operations platform for a foundation](https://www.enter20.com/en/work/foundation-operations-platform/): Design of an internal platform to organise people, projects, modules, permissions and operational reporting without exposing sensitive data. - [Indicators and dashboards for social monitoring](https://www.enter20.com/en/work/social-impact-dashboards/): Structuring of data and indicators so that foundations and associations can better manage, report on and explain their impact. - [Survey pipeline and qualitative analysis](https://www.enter20.com/en/work/survey-qualitative-analysis/): Transformation of survey exports into reviewable analytical outputs with Python, pandas, Excel and human judgement. ### Related articles - [Why AI projects fail when the data model is not understood](https://www.enter20.com/en/blog/why-ai-projects-fail-without-understanding-data-model/) (2026-06-23): AI can speed up work, but on its own it does not fix ambiguous data, blurred responsibilities or poorly defined processes. - [From Excel chaos to useful indicators for foundations and SMEs](https://www.enter20.com/en/blog/from-excel-chaos-to-useful-indicators/) (2026-03-24): Excel is not the problem. The problem arises when each spreadsheet defines reality in a different way and nobody knows which figure is authoritative. - [Dashboards are not the starting point: they are the visible part of the data system](https://www.enter20.com/en/blog/dashboards-are-the-visible-part-of-the-data-system/) (2025-06-20): A useful dashboard depends on processes, definitions, data quality, ownership and review routines that usually sit outside the screen. ### Does this fit your situation? Briefly describe the operational, data or AI problem. The first reply can help to guide the type of diagnostic. Contact: [contacta@enter20.com](https://www.enter20.commailto:contacta@enter20.com) · [Contact form](https://www.enter20.com/en/contact/) · [Diagnostic questionnaire](https://evaluo.enter20.com) --- ## Bespoke operational tools > Small internal applications for when Excel, forms and disconnected SaaS no longer support the daily work. - URL: https://www.enter20.com/en/services/bespoke-operational-tools/ - Español: https://www.enter20.com/servicios/herramientas-operativas/ - enter 2.0 — Practical AI, governed data, dashboards, automation and information systems for organisations that need to make better decisions. Design and build of tools focused on real processes: beneficiaries, projects, contacts, time tracking, administration, permissions, auditing and exports. ### What can remain after the work - Internal applications with roles, modules and access controls. - Workflows for creation, editing, review, closure and reporting. - Integration with existing databases and systems where appropriate. - User documentation and handover to the team. ### Technical and operational proof - Modular platforms with Firebase Auth, Supabase/PostgreSQL, React, Vite and React Admin. - Work on managing people, projects, employees, groups, activities and permissions. - Practice with Cloudflare and Firebase Hosting deployments and automated Linux environments. ### Anonymised examples - [Modular operations platform for a foundation](https://www.enter20.com/en/work/foundation-operations-platform/): Design of an internal platform to organise people, projects, modules, permissions and operational reporting without exposing sensitive data. ### Related articles - [Working with AI assistants without losing the thread: rules and memory in the repository](https://www.enter20.com/en/blog/working-with-ai-assistants-rules-memory-in-repository/) (2026-10-23): If a project's context lives in a tool's chat, it is lost when the tool is closed. If it lives in the repository, any assistant or person can carry on from where the previous one left off. - [Layered security for small internal tools: identity at the edge and failing closed](https://www.enter20.com/en/blog/layered-security-internal-tools-identity-at-edge-fail-closed/) (2026-10-06): An internal tool does not need a VPN or an exposed server. It needs identity before anything can be reached, a service that fails closed when configuration is missing, and tunnels instead of open ports. - [From PDF to reviewed data: fingerprint, evidence and review queue](https://www.enter20.com/en/blog/from-pdf-to-reviewed-data-fingerprint-evidence-review-queue/) (2026-09-18): Extracting data from invoices, payslips or calls for proposals is easy to promise and hard to make reliable. Reliability comes from the document's fingerprint, the evidence kept alongside each data point and a review process that does not get in the way. - [Permissions live in the database, not on the screen](https://www.enter20.com/en/blog/permissions-live-in-the-database-not-the-screen/) (2026-08-13): When several departments or companies share a tool, who sees what must be decided in the database. The interface can fail; a rule on the server does not. - [From Excel chaos to useful indicators for foundations and SMEs](https://www.enter20.com/en/blog/from-excel-chaos-to-useful-indicators/) (2026-03-24): Excel is not the problem. The problem arises when each spreadsheet defines reality in a different way and nobody knows which figure is authoritative. - [Dashboards are not the starting point: they are the visible part of the data system](https://www.enter20.com/en/blog/dashboards-are-the-visible-part-of-the-data-system/) (2025-06-20): A useful dashboard depends on processes, definitions, data quality, ownership and review routines that usually sit outside the screen. ### Does this fit your situation? Briefly describe the operational, data or AI problem. The first reply can help to guide the type of diagnostic. Contact: [contacta@enter20.com](https://www.enter20.commailto:contacta@enter20.com) · [Contact form](https://www.enter20.com/en/contact/) · [Diagnostic questionnaire](https://evaluo.enter20.com) --- ## Fractional IT Director > A senior part-time IT function for organisations that are too small to maintain IT leadership of their own. - URL: https://www.enter20.com/en/services/fractional-it-director/ - Español: https://www.enter20.com/servicios/director-de-informatica/ - enter 2.0 — Practical AI, governed data, dashboards, automation and information systems for organisations that need to make better decisions. For foundations, associations, SMEs and non-profit sector teams that need executive-level judgement on technology, data, security, suppliers and continuity, but cannot justify a full-time in-house IT leadership role. ### Fractional senior IT leadership The service provides an IT leadership function for organisations that need judgement, follow-up and technology coordination, but lack the scale to bring that role in-house. ### What can remain after the work - Regular liaison with senior management to turn business needs into IT decisions. - An annual plan for systems, data, security, suppliers, continuity and priorities. - Review of purchases, contracts, licences, domains, access, backups and supplier dependency. - Support for internal or external teams so that technical projects do not go without direction. ### Technical and operational proof - Combined experience in management, architecture, data, BI, operational security, automation and deployments. - A great deal of accumulated work with non-profit sector organisations, foundations and projects with limited technical resources. - Ability to talk to senior management, administration, social teams and technical suppliers without losing operational detail. ### Anonymised examples - [Modular operations platform for a foundation](https://www.enter20.com/en/work/foundation-operations-platform/): Design of an internal platform to organise people, projects, modules, permissions and operational reporting without exposing sensitive data. - [Document automation with Python and human review](https://www.enter20.com/en/work/python-document-automation/): Workflows to extract text, classify documents and generate structured indexes from administrative PDFs. ### Related articles - [Organisational memory: keeping knowledge in the company when the AI tool changes](https://www.enter20.com/en/blog/organisational-memory-keep-knowledge-when-changing-ai-tools/) (2026-11-09): AI assistants need context, and that context is usually built inside a vendor's tool. Curating it as the organisation's own knowledge cards, with sources, an owner and a review date, makes it reviewable and portable. - [Layered security for small internal tools: identity at the edge and failing closed](https://www.enter20.com/en/blog/layered-security-internal-tools-identity-at-edge-fail-closed/) (2026-10-06): An internal tool does not need a VPN or an exposed server. It needs identity before anything can be reached, a service that fails closed when configuration is missing, and tunnels instead of open ports. - [A backup is only as good as its restore](https://www.enter20.com/en/blog/backup-only-as-good-as-its-restore/) (2026-08-31): The backup log can say ‘successful’ and the restore can still fail. Layered backups, test restores and written decisions are what keep continuity in place. - [Permissions live in the database, not on the screen](https://www.enter20.com/en/blog/permissions-live-in-the-database-not-the-screen/) (2026-08-13): When several departments or companies share a tool, who sees what must be decided in the database. The interface can fail; a rule on the server does not. ### Does this fit your situation? Briefly describe the operational, data or AI problem. The first reply can help to guide the type of diagnostic. Contact: [contacta@enter20.com](https://www.enter20.commailto:contacta@enter20.com) · [Contact form](https://www.enter20.com/en/contact/) · [Diagnostic questionnaire](https://evaluo.enter20.com) --- ## Document and data automation > Processes PDFs, spreadsheets, surveys and repetitive exports with scripts, OCR, rules and human review. - URL: https://www.enter20.com/en/services/document-data-automation/ - Español: https://www.enter20.com/servicios/automatizacion-documentos-datos/ - enter 2.0 — Practical AI, governed data, dashboards, automation and information systems for organisations that need to make better decisions. Automations for the dull but critical work: extraction, classification, validation, renaming, reconciliation, summarising, review routes and deliverables in CSV, Excel or databases. ### What can remain after the work - Python pipelines for PDFs, OCR, CSV, Excel and administrative documents. - Rule-based classification, with AI support where privacy and risk allow. - Traceability of exceptions, imputations and human decisions. - Outputs ready for reporting, archiving or loading into systems. ### Technical and operational proof - PDF/OCR extraction tools, invoices, receipts, payslips and bank documents. - Survey analysis with pandas, parquet, Excel, codebooks and review queues. - Use of YAML rules, post-processors and AI models as controlled support. ### Anonymised examples - [Survey pipeline and qualitative analysis](https://www.enter20.com/en/work/survey-qualitative-analysis/): Transformation of survey exports into reviewable analytical outputs with Python, pandas, Excel and human judgement. - [Document automation with Python and human review](https://www.enter20.com/en/work/python-document-automation/): Workflows to extract text, classify documents and generate structured indexes from administrative PDFs. ### Related articles - [Organisational memory: keeping knowledge in the company when the AI tool changes](https://www.enter20.com/en/blog/organisational-memory-keep-knowledge-when-changing-ai-tools/) (2026-11-09): AI assistants need context, and that context is usually built inside a vendor's tool. Curating it as the organisation's own knowledge cards, with sources, an owner and a review date, makes it reviewable and portable. - [From PDF to reviewed data: fingerprint, evidence and review queue](https://www.enter20.com/en/blog/from-pdf-to-reviewed-data-fingerprint-evidence-review-queue/) (2026-09-18): Extracting data from invoices, payslips or calls for proposals is easy to promise and hard to make reliable. Reliability comes from the document's fingerprint, the evidence kept alongside each data point and a review process that does not get in the way. - [From cost savings to irrelevance: the danger of automating without redesigning your processes](https://www.enter20.com/en/blog/danger-of-automating-without-redesigning-processes/) (2026-07-08): Automating inefficient tasks moves the disorder onto a faster platform. Real value comes from redesigning the process architecture. - [How to use AI safely in organisations that handle sensitive documents](https://www.enter20.com/en/blog/using-ai-safely-with-sensitive-documents/) (2025-09-19): Using AI safely with documents depends on classification, data minimisation, human review, contracts, records and local alternatives when the risk demands them. ### Does this fit your situation? Briefly describe the operational, data or AI problem. The first reply can help to guide the type of diagnostic. Contact: [contacta@enter20.com](https://www.enter20.commailto:contacta@enter20.com) · [Contact form](https://www.enter20.com/en/contact/) · [Diagnostic questionnaire](https://evaluo.enter20.com) --- ## IT governance, continuity and operations > Clarifies who controls the systems, where the data lives, how access is protected and what happens if something fails. - URL: https://www.enter20.com/en/services/it-governance-continuity/ - Español: https://www.enter20.com/servicios/gobernanza-continuidad-it/ - enter 2.0 — Practical AI, governed data, dashboards, automation and information systems for organisations that need to make better decisions. Support for organisations that depend on technology but do not have a complete IT structure: accounts, access, backups, deployments, suppliers, documentation, recovery and continuity. ### What can remain after the work - Inventory of systems, accounts, owners and sensitive data. - Review of access, roles, backups, recovery and dependencies. - Practical criteria for operating without depending on a single person or supplier. - Runbooks and documentation that the team can use. ### Technical and operational proof - Work with RLS, module-level authorisation, backups, migrations, domains, Cloudflare and Linux environments. - Operational documentation, handoffs, production plans and rollback routes. - A proportionate approach to security: enough control without pointless bureaucracy. ### Anonymised examples - [Modular operations platform for a foundation](https://www.enter20.com/en/work/foundation-operations-platform/): Design of an internal platform to organise people, projects, modules, permissions and operational reporting without exposing sensitive data. - [Document automation with Python and human review](https://www.enter20.com/en/work/python-document-automation/): Workflows to extract text, classify documents and generate structured indexes from administrative PDFs. ### Related articles - [Working with AI assistants without losing the thread: rules and memory in the repository](https://www.enter20.com/en/blog/working-with-ai-assistants-rules-memory-in-repository/) (2026-10-23): If a project's context lives in a tool's chat, it is lost when the tool is closed. If it lives in the repository, any assistant or person can carry on from where the previous one left off. - [Layered security for small internal tools: identity at the edge and failing closed](https://www.enter20.com/en/blog/layered-security-internal-tools-identity-at-edge-fail-closed/) (2026-10-06): An internal tool does not need a VPN or an exposed server. It needs identity before anything can be reached, a service that fails closed when configuration is missing, and tunnels instead of open ports. - [A backup is only as good as its restore](https://www.enter20.com/en/blog/backup-only-as-good-as-its-restore/) (2026-08-31): The backup log can say ‘successful’ and the restore can still fail. Layered backups, test restores and written decisions are what keep continuity in place. - [Permissions live in the database, not on the screen](https://www.enter20.com/en/blog/permissions-live-in-the-database-not-the-screen/) (2026-08-13): When several departments or companies share a tool, who sees what must be decided in the database. The interface can fail; a rule on the server does not. - [AI proposes, a person decides: how to inventory AI use across your tools](https://www.enter20.com/en/blog/ai-proposes-a-person-decides-inventory-ai-use/) (2026-07-26): Before debating which model to use, it is worth knowing, for each tool, what the AI does, what it never does, where it runs and who reviews its output. - [From cost savings to irrelevance: the danger of automating without redesigning your processes](https://www.enter20.com/en/blog/danger-of-automating-without-redesigning-processes/) (2026-07-08): Automating inefficient tasks moves the disorder onto a faster platform. Real value comes from redesigning the process architecture. - [What an AI adoption diagnostic should include before you buy tools](https://www.enter20.com/en/blog/what-ai-adoption-diagnostic-should-include-before-buying-tools/) (2025-12-18): A serious diagnostic separates wishes, processes, data, risks, people and decisions before any vendors or licences are chosen. - [How to use AI safely in organisations that handle sensitive documents](https://www.enter20.com/en/blog/using-ai-safely-with-sensitive-documents/) (2025-09-19): Using AI safely with documents depends on classification, data minimisation, human review, contracts, records and local alternatives when the risk demands them. ### Does this fit your situation? Briefly describe the operational, data or AI problem. The first reply can help to guide the type of diagnostic. Contact: [contacta@enter20.com](https://www.enter20.commailto:contacta@enter20.com) · [Contact form](https://www.enter20.com/en/contact/) · [Diagnostic questionnaire](https://evaluo.enter20.com) --- ## Lab: solutions you can try > Interactive mini-apps with fictional data that show how enter 2.0 works: invoices with evidence, a management cockpit, a decision simulator, a tender radar, documents with local AI and organisational memory. - URL: https://www.enter20.com/en/lab/ - Español: https://www.enter20.com/laboratorio/ - enter 2.0 — Practical AI, governed data, dashboards, automation and information systems for organisations that need to make better decisions. Each mini-app reproduces how a solution built or designed by enter 2.0 works. The data is fictional (the invented company «Alisio») and each one declares its status: production, pilot, prototype or design. Everything you see in the demos is fictional: the company «Alisio», the people, the amounts and the documents. Nothing leaves your browser. ### Four states, nothing glossed over - **Production.** In real use by an organisation. - **Pilot.** In controlled use, with acceptance or scope still open. - **Prototype.** It works and has been shown; it is not in daily use. - **Design.** Proposed service; the mock-up illustrates the idea. - [Invoice and payslip inbox with evidence](https://www.enter20.com/en/lab/facturas/) — Pilot: Upload PDFs: data extracted with its evidence, duplicates detected, payslips matched against the bank. - [Management cockpit](https://www.enter20.com/en/lab/cockpit/) — Production: Cross-department matters with an owner, a next step and a committed date. Each area sees its own. - [Dashboard with a decision simulator](https://www.enter20.com/en/lab/escenarios/) — Prototype: Indicators by stage and «Se decide» (it gets decided) switches: which indicators will not arrive on time if a decision is put off. - [Tender and grant radar](https://www.enter20.com/en/lab/licitaciones/) — Prototype: PDF of the call → AI-drafted summary sheet reviewed by people → blind vote → traceable decision. - [ENTERBOX: the AI goes to the documents](https://www.enter20.com/en/lab/caja-documental/) — Pilot: A device in the office turns documents into searchable information, with local processing and the sources in view. - [Organisational memory: the knowledge stays in the company](https://www.enter20.com/en/lab/memoria-organizativa/) — Design: Reviewed definitions, procedures and decisions in the company's own files, ready for a change of AI tool. This Lab is a selection. The full catalogue, with guided walkthroughs for management and IT leadership, is shown in a private demonstration. --- ## Invoice and payslip inbox with evidence > Upload PDFs: data extracted with its evidence, duplicates detected, payslips matched against the bank. - URL: https://www.enter20.com/en/lab/facturas/ - Español: https://www.enter20.com/laboratorio/facturas/ - enter 2.0 — Practical AI, governed data, dashboards, automation and information systems for organisations that need to make better decisions. Upload PDFs: data extracted with its evidence, duplicates detected, payslips matched against the bank. - Pilot: Controlled pilot in an SME. Payment batches and the connection to the accounting software are still to be tested. - Fictional data: Everything you see in the demos is fictional: the company «Alisio», the people, the amounts and the documents. Nothing leaves your browser. ### For management #### The problem PDF invoices arriving through five different channels, data typed in by hand, duplicates that get paid twice and payslips that have to be matched against the bank one by one. #### What it does - Every PDF is given a fingerprint: a duplicate is detected even if the file name changes. - Tax ID, number, date, net amount, VAT and total extracted, each with its evidence in the document. - Supplier recognised by its aliases. - On approval, a copy is archived under a standardised name; the original is left untouched. - Payslips: the month's PDF is split by person and matched with the bank transfer. #### What you gain - Less typing and fewer errors when recording invoices. - No duplicate payments through oversight. - Payroll evidence ready for audits and grant claims. #### Try this - Select an invoice and hover over the data: the evidence lights up. - Open the invoice flagged as a duplicate. - Approve one and look at the name it is archived under. - In «Nóminas» (payslips), review the weak-rule warning. ### For IT leadership #### How it is built - Local web application (FastAPI + PostgreSQL) published through Cloudflare Tunnel; local OCR with Tesseract. - Rule-based extraction; reprocessing with an AI model only if it is switched on. #### Security - SHA-256 fingerprint per document and an immutable original. - Data does not leave the office unless the external model is switched on; the system warns if configuration is missing. - Protected access; Cloudflare Access is mandatory to expose it permanently. #### Use of AI External AI switched off by default; when it is used, every proposed value keeps its evidence and is approved by a person. #### Operations Separate CSV exports of invoices and payments for the external accountants. --- ## Management cockpit > Cross-department matters with an owner, a next step and a committed date. Each area sees its own. - URL: https://www.enter20.com/en/lab/cockpit/ - Español: https://www.enter20.com/laboratorio/cockpit/ - enter 2.0 — Practical AI, governed data, dashboards, automation and information systems for organisations that need to make better decisions. Cross-department matters with an owner, a next step and a committed date. Each area sees its own. - Production: In daily use by the management team of a service centre since September 2026, in a pilot phase. - Fictional data: Everything you see in the demos is fictional: the company «Alisio», the people, the amounts and the documents. Nothing leaves your browser. ### For management #### The problem Matters that cut across areas get lost among emails, WhatsApp and meetings. Nobody knows who has the ball or when it is due. #### What it does - Every matter has a lead area, an owner and someone in charge of the next step. - «Hoy» (today), «Mis responsabilidades» (my responsibilities), «Con novedades» (with updates) and «Pendientes de área» (pending for the area) views. - When the next step is assigned, the status changes by itself and an automatic comment is recorded. - To close a matter you have to write down what was learnt. - Follow-up email drafted with the full history of the case. #### What you gain - Shorter meetings: you go through the list, not each person's memory. - Commitments with a date and an owner, visible to management. - Each department sees only what affects it. #### Try this - Switch person at the top (Gerencia, Mantenimiento…) and see how what is visible changes. - Open a matter and assign the next step to another area. - Try to close it without writing down the lesson learnt. - Generate the follow-up email. ### For IT leadership #### How it is built - React + managed PostgreSQL (Supabase) + a Cloudflare Worker for the assets and for sending authenticated email. - Passwordless access with a 6-digit code sent by email. #### Security - Privacy through Row Level Security: each area only «sees that it exists» for what it shares; management sees everything. - Writes only through functions with version control (optimistic concurrency): nobody overwrites someone else's change. - Full audit trail and automatic comment in the same transaction. #### Operations - Mandatory backup before every migration. - User manual built into the application itself. --- ## Dashboard with a decision simulator > Indicators by stage and «Se decide» (it gets decided) switches: which indicators will not arrive on time if a decision is put off. - URL: https://www.enter20.com/en/lab/escenarios/ - Español: https://www.enter20.com/laboratorio/escenarios/ - enter 2.0 — Practical AI, governed data, dashboards, automation and information systems for organisations that need to make better decisions. Indicators by stage and «Se decide» (it gets decided) switches: which indicators will not arrive on time if a decision is put off. - Prototype: Deployed privately for the decision-making body of a foundation; awaiting its validation. - Fictional data: Everything you see in the demos is fictional: the company «Alisio», the people, the amounts and the documents. Nothing leaves your browser. ### For management #### The problem Dashboards show the past. What a management meeting needs is to see what happens if something is not decided today. #### What it does - Three questions: How much did we do? Did we do it well? Is anyone better off? - Stage selector: today, after the meeting, after defining criteria, and target. - «Se decide» switches: turn one off and you see which indicators stop arriving on time. - Full-screen presentation mode and printing. #### What you gain - Meetings that end in decisions, not in reports. - Seeing the cost of putting off a decision before putting it off. - Figures with a cut-off date; never made-up projections. #### Try this - Change stage and watch the indicators move forward. - Turn off «Definición común de cliente activo» (shared definition of an active client). - Note which indicators change to «No llega» (will not arrive). ### For IT leadership #### How it is built - HTML, CSS and JavaScript modules with no framework or dependencies; scenario engine with automated tests. - Cloudflare Worker with Access (one-time code) that fails closed if configuration is missing. #### Security - Strict CSP and an automatic content check before publishing: no personal data reaches the page. - Future stages show a status, never a made-up number. #### Operations Automated QA at the tablet and projector resolutions, with a PDF per stage in case the network fails. --- ## Tender and grant radar > PDF of the call → AI-drafted summary sheet reviewed by people → blind vote → traceable decision. - URL: https://www.enter20.com/en/lab/licitaciones/ - Español: https://www.enter20.com/laboratorio/licitaciones/ - enter 2.0 — Practical AI, governed data, dashboards, automation and information systems for organisations that need to make better decisions. PDF of the call → AI-drafted summary sheet reviewed by people → blind vote → traceable decision. - Prototype: Prototype deployed: the AI summary sheet, voting and milestones work; the automatic connectors to official gazettes are at the design stage. - Fictional data: Everything you see in the demos is fictional: the company «Alisio», the people, the amounts and the documents. Nothing leaves your browser. ### For management #### The problem New calls come out every week. Reading them takes hours, and deciding which ones to bid for depends on who shouts loudest in the meeting. #### What it does - You upload the PDFs and the system prepares a summary sheet: subject, deadline, amount, requirements. - Every value proposed by the AI stays flagged until a person reviews it. - Blind vote in two phases: «shall we study it?» and «shall we bid?». - Strategic value with 8 criteria scored by people. - Milestones (solvency, remedying deficiencies, award) and a printable report. #### What you gain - Fewer hours spent reading tender documents. - Decisions on whether to bid without the bias of who speaks first. - A record of why the answer was yes or no. #### Try this - Upload a sample call and watch the process. - Review a value flagged as AI. - Vote as three different people and see how the decision is reached. ### For IT leadership #### How it is built - Cloudflare Worker + D1 and R2 in the EU + Workflows for the step-by-step process with retries. - Interchangeable AI provider layer. #### Security - Only the public text of the call reaches the AI, never votes or names. - Deduplication by the SHA-256 fingerprint of each PDF. #### Use of AI - JSON validated with a retry; if it fails again, the sheet is left as «revisar a mano» (review by hand). - Every call logged with tokens and cost. #### Operations 27 automated tests. --- ## ENTERBOX: the AI goes to the documents > A device in the office turns documents into searchable information, with local processing and the sources in view. - URL: https://www.enter20.com/en/lab/caja-documental/ - Español: https://www.enter20.com/laboratorio/caja-documental/ - enter 2.0 — Practical AI, governed data, dashboards, automation and information systems for organisations that need to make better decisions. A device in the office turns documents into searchable information, with local processing and the sources in view. - Pilot: Pilot in a services SME: inventory, local PDF/OCR extraction, master data and document viewer operational according to the documentation of 27/10/2026. The mock-up also illustrates proposed features; organisational memory and OKF are a separate case, at the Design stage. - Fictional data: Everything you see in the demos is fictional: the company «Alisio», the people, the amounts and the documents. Nothing leaves your browser. ### For management #### The problem Years of contracts, invoices and quotations on a file server. Nobody knows what is there, what is duplicated or what sensitive data it holds, and uploading it all to a cloud AI is not an option. #### What it does - Inventory of the server without modifying the originals. - Local PDF/OCR text extraction, master data and a viewer for the cited document in the pilot. - The mock-up shows a proposed traffic-light rating and three levels: metadata, local content, and cloud with recorded authorisation. - Classification proposals and their approval are simulated with fictitious evidence. - Organisational memory extends this approach with curated, portable context; it is listed separately as Design. #### What you gain - Designed for knowing what is there and locating the evidence. - Consulting structured information alongside its source document. - Deciding what is processed locally and what would require additional authorisation. #### Try this - Go through the traffic-light rating folder by folder. - Try to switch on the «nube» (cloud) level and see what it asks for. - Approve or reject a classification proposal. ### For IT leadership #### How it is built - Mini PC with Ubuntu Server, PostgreSQL, PDF/OCR extraction and a local query portal; remote administration through Tunnel and Access. - Reading throttled by schedule, resources and temperature to limit the impact on the office. #### Security - Encrypted disk (LUKS2 with TPM2) and Secure Boot; SSH with key only. - Source mounted read-only; separate database roles for ingestion, review and querying. - No content goes out to a cloud AI without recorded authorisation. #### Use of AI Local PDF/OCR extraction active. The assisted classification and the cloud authorisation in this mock-up illustrate the design; they are not evidence that a model is used in the pilot. #### Operations - Layered backups and decisions recorded as ADRs; an adaptation of the remote backup is still pending according to the documentation of 27/10/2026. - The figures, logs and controls shown here are fictitious. --- ## Organisational memory: the knowledge stays in the company > Reviewed definitions, procedures and decisions in the company's own files, ready for a change of AI tool. - URL: https://www.enter20.com/en/lab/memoria-organizativa/ - Español: https://www.enter20.com/laboratorio/memoria-organizativa/ - enter 2.0 — Practical AI, governed data, dashboards, automation and information systems for organisations that need to make better decisions. Reviewed definitions, procedures and decisions in the company's own files, ready for a change of AI tool. - Design: Proposed service, with no proven implementation in an organisation. This mock-up runs on fictitious data; it does not run AI or apply real permissions. Sample export based on OKF v0.2, consulted on 27/10/2026. - Fictional data: Everything you see in the demos is fictional: the company «Alisio», the people, the amounts and the documents. Nothing leaves your browser. ### For management #### The problem Every new starter or change of tool means explaining all over again how the company works. There are contradictory procedures and nobody knows which version has been reviewed. #### What it does - Selecting authorised sources and turning them into Markdown context sheets. - A person from the area resolves contradictions, corrects the draft and approves it, giving a reason. - Each sheet keeps its sources, owner, version and review date. - Sharing with each team the context that concerns it; withdrawing from use whatever has expired or is affected by a change of source. - Exporting the example as Markdown or as an OKF package with sources and history. #### What you gain - Designed to ease onboarding and handovers with reviewed knowledge. - Keeping a shared standard across areas and tools. - Keeping the context and taking it with you when changing AI provider. #### Try this - In «Revisar» (review), compare the 30-day and 45-day notice periods and apply the rule currently in force. - Correct the text, write the reason, confirm the check and approve the sheet. - Look up the renewal and download the OKF package. - Switch profile or simulate a change of source to see what stops being distributed. ### For IT leadership #### How it is built - Markdown library with metadata, sources and history; storage and accounts under the company's control as the implementation goal. - OKF v0.2 as the interchange format: concepts with YAML, index.md, log.md and sources included. - ENTERBOX can contribute local document processing; organisational curation adds review, owners and maintenance. #### Security - Permissions before building the context an assistant receives; the profile selector is only simulated in this demo. - The sample policy excludes drafts, overdue reviews and sheets whose sources have changed. - The portability of the format is no substitute for the company's own accounts, backups, permissions or an exit procedure. The exported package is not encrypted. #### Use of AI The AI would propose drafts with sources; a person from the area would approve. Here the proposal and the query are deterministic simulations, with no calls to models. #### Operations - Start with one bounded process and extend area by area with agreed owners and reviews. - OKF is an evolving format. The x_alisio_* extensions and the distribution filters are specific to this mock-up. --- ## Work and anonymised cases > Public cases covering operational platforms, indicators, dashboards, surveys and document automation, anonymised by default. - URL: https://www.enter20.com/en/work/ - Español: https://www.enter20.com/trabajos/ - enter 2.0 — Practical AI, governed data, dashboards, automation and information systems for organisations that need to make better decisions. Cases are presented anonymised by default. The aim is to show judgement, scope and operational value, not to publish private data or internal infrastructure. - [Modular operations platform for a foundation](https://www.enter20.com/en/work/foundation-operations-platform/): Design of an internal platform to organise people, projects, modules, permissions and operational reporting without exposing sensitive data. - [Indicators and dashboards for social monitoring](https://www.enter20.com/en/work/social-impact-dashboards/): Structuring of data and indicators so that foundations and associations can better manage, report on and explain their impact. - [Survey pipeline and qualitative analysis](https://www.enter20.com/en/work/survey-qualitative-analysis/): Transformation of survey exports into reviewable analytical outputs with Python, pandas, Excel and human judgement. - [Document automation with Python and human review](https://www.enter20.com/en/work/python-document-automation/): Workflows to extract text, classify documents and generate structured indexes from administrative PDFs. --- ## Modular operations platform for a foundation > Design of an internal platform to organise people, projects, modules, permissions and operational reporting without exposing sensitive data. - URL: https://www.enter20.com/en/work/foundation-operations-platform/ - Español: https://www.enter20.com/trabajos/plataforma-operativa-fundacion/ - enter 2.0 — Practical AI, governed data, dashboards, automation and information systems for organisations that need to make better decisions. - Client type: Foundation, anonymised by default - Technologies: React, Vite, React Admin, Firebase Auth, Supabase, PostgreSQL, SQL, Cloudflare ### Problem The organisation needed to move from scattered data and manual processes to a common operational base with access control, modules and reporting capability. ### Constraints - Sensitive personal and operational data. - Need to coexist with existing tools. - Non-technical teams who needed clear screens and reliable exports. - Gradual rollout by module to reduce risk. ### What was done - Data model for people, projects, groups, activities, employees and the relationships between modules. - React/Vite applications and administration with React Admin. - Firebase authentication and authorisation against Supabase/PostgreSQL. - Deployment routes, documentation, deactivation controls and operational validation. ### Governance and security - Access by module and active user. - Hard delete disabled on administration screens. - SQL templates, backups and post-migration checks. - Separation between public information and internal documentation. ### Result The organisation gained a clearer base for managing operations, permissions and reporting without multiplying independent spreadsheets. ### What it demonstrates - Ability to bring together process, data, authentication and operational screens. - Judgement to build module by module rather than attempt a wholesale replacement in one go. - Attention to security, continuity and handover. ### Connected areas - [Data, indicators and dashboards](https://www.enter20.com/en/services/data-indicators-dashboards/) - [Bespoke operational tools](https://www.enter20.com/en/services/bespoke-operational-tools/) - [Fractional IT Director](https://www.enter20.com/en/services/fractional-it-director/) - [IT governance, continuity and operations](https://www.enter20.com/en/services/it-governance-continuity/) --- ## Indicators and dashboards for social monitoring > Structuring of data and indicators so that foundations and associations can better manage, report on and explain their impact. - URL: https://www.enter20.com/en/work/social-impact-dashboards/ - Español: https://www.enter20.com/trabajos/indicadores-dashboards-impacto-social/ - enter 2.0 — Practical AI, governed data, dashboards, automation and information systems for organisations that need to make better decisions. - Client type: Social organisations and public-interest projects - Technologies: PostgreSQL, Supabase, React, Recharts, R, Shiny, Google Sheets, CSV ### Problem There was data on activity, people, projects and territory, but no integrated view for senior management, teams and funders. ### Constraints - Sources with different formats and levels of quality. - Need for indicators that non-technical people can understand. - Separation between internal reporting and public communication. - Changes of criteria while the model was being defined. ### What was done - Definition of indicators and reporting structure. - Preparation of clean views and datasets for visualisation. - Dashboards and visualisations with React, Recharts, R/Shiny and spreadsheets where they fitted. - Documentation of criteria so that the team understands what each indicator measures. ### Governance and security - Traceability between source data, indicator and visualisation. - Anonymisation or aggregation criteria where the data requires it. - Separation between public and operational views. ### Result Teams were able to move from manual counts to a more objective conversation about activity, coverage, trends and data needs. ### What it demonstrates - Ability to translate social activity into useful data. - Understanding of reporting for senior management, funders and operational teams. - A focus on decisions, not decorative dashboards. ### Connected areas - [AI and data diagnostic](https://www.enter20.com/en/services/ai-data-diagnostic/) - [Data, indicators and dashboards](https://www.enter20.com/en/services/data-indicators-dashboards/) --- ## Survey pipeline and qualitative analysis > Transformation of survey exports into reviewable analytical outputs with Python, pandas, Excel and human judgement. - URL: https://www.enter20.com/en/work/survey-qualitative-analysis/ - Español: https://www.enter20.com/trabajos/encuestas-analisis-cualitativo/ - enter 2.0 — Practical AI, governed data, dashboards, automation and information systems for organisations that need to make better decisions. - Client type: Evaluation and social analysis project - Technologies: Python, pandas, Parquet, Excel, CSV, pytest, R ### Problem Open-ended responses and survey data needed coding, cleaning, traceability and understandable deliverables for later analysis. ### Constraints - Open-ended responses with linguistic variation and interpretive judgement. - Need to retain human review and not delegate conclusions to a black box. - Deliverables in formats that non-technical users can handle. ### What was done - Python scripts to import, clean, code and review data. - Codebooks, review queues, audit of imputations and Excel outputs. - Qualitative and quantitative synthesis with traceability of the process. - Documentation so that the workflow can be repeated with new batches of data. ### Governance and security - Human review at points of interpretive decision. - Audit of imputations and exceptions. - Separation of source data, processed data and deliverables. ### Result The analysis moved from unwieldy exports to a reviewable, reusable base for conclusions, reports and improvements to the questionnaire. ### What it demonstrates - Careful automation where context matters. - Ability to combine qualitative and quantitative data. - Delivery in formats that are useful to research or management teams. ### Connected areas - [Data, indicators and dashboards](https://www.enter20.com/en/services/data-indicators-dashboards/) - [Document and data automation](https://www.enter20.com/en/services/document-data-automation/) --- ## Document automation with Python and human review > Workflows to extract text, classify documents and generate structured indexes from administrative PDFs. - URL: https://www.enter20.com/en/work/python-document-automation/ - Español: https://www.enter20.com/trabajos/automatizacion-documental-python/ - enter 2.0 — Practical AI, governed data, dashboards, automation and information systems for organisations that need to make better decisions. - Client type: Administrative operations, anonymised - Technologies: Python, OCR, YAML, CSV, JSONL, PDF, LLM with review ### Problem PDF documents, invoices, receipts and payslips consumed administrative time and caused errors when renaming, classifying or extracting metadata. ### Constraints - Uneven quality of PDFs and OCR. - Sensitive tax, banking and employment data. - Need to preserve the original file and record exceptions. - AI used only as support when fields are missing or confidence drops. ### What was done - Python tools for text extraction with OCR as a fallback. - Rule-based classification, document routing and CSV/JSONL indexes. - Extraction of metadata, amounts, dates, suppliers and centre codes. - Dry-run options, text sidecars, auditing and controlled application. ### Governance and security - Local or controlled processing where privacy requires it. - Dry-run before applying moves or renames. - Preservation of the original document and traceability of rules. ### Result Repetitive filing and extraction tasks moved to a workflow that is faster, reviewable and less dependent on manual memory. ### What it demonstrates - Practical automation of real administrative processes. - Prudent use of AI on sensitive documents. - Design of small tools that save work without imposing a full platform. ### Connected areas - [Fractional IT Director](https://www.enter20.com/en/services/fractional-it-director/) - [Document and data automation](https://www.enter20.com/en/services/document-data-automation/) - [IT governance, continuity and operations](https://www.enter20.com/en/services/it-governance-continuity/) --- ## Working method > The enter 2.0 method: diagnostic, operating model, prototype, production, governance and handover. - URL: https://www.enter20.com/en/method/ - Español: https://www.enter20.com/metodo/ - enter 2.0 — Practical AI, governed data, dashboards, automation and information systems for organisations that need to make better decisions. The work combines leadership, operations and technical work. The goal is not to produce a polished demo, but to leave behind decisions, systems and routines that withstand daily use. 1. **Listen and map.** Processes, sources, documents, roles, recurring problems, decisions and risks. 2. **Separate the problem from the solution.** Not everything needs AI. The aim is to decide whether process, data, a dashboard, a tool, automation or governance is the right answer. 3. **Prototype with controlled real data.** Value is validated with a small scope, clear criteria and protection of sensitive information. 4. **Move to operational use.** Screens, scripts, dashboards or documentation are adjusted so that the team can use them without unnecessary dependency. 5. **Govern and hand over.** Owners, permissions, backups, review routines, indicators and next steps are documented. ### Pragmatic, verifiable and transferable - Use AI where it reduces friction, not where it adds risk unnecessarily. - Design data and indicators before finalising dashboards. - Prefer small, maintainable systems to oversized platforms. - Document decisions, permissions and operations so that the team does not depend on informal memory. - Protect sensitive data by design. --- ## About enter 2.0 > enter 2.0 is a senior consultancy based in Navarra, with broad experience in the non-profit sector and work in AI, data, BI, automation, operational systems and IT governance. - URL: https://www.enter20.com/en/about/ - Español: https://www.enter20.com/sobre-enter-20/ - enter 2.0 — Practical AI, governed data, dashboards, automation and information systems for organisations that need to make better decisions. enter 2.0 is based in Navarra and works with organisations that need to get their information in order, improve reporting, automate tasks and adopt AI in a practical, safe way. The commercial focus is close and local, but the nature of analysis and digital work makes it possible to collaborate with organisations in any territory when the fit is clear. ### Not just development. Not just consultancy. It is about solving the information system that underpins the work. The approach combines experience in IT, management, data, BI, automation, operational security and AI adoption. The conversation can start with leadership, administration, programmes or IT, but it must end in a concrete improvement to the work. There is extensive experience in the non-profit sector: foundations, associations, social projects, small teams, sensitive data, funder reporting and indicators of activity or impact. Past experience is presented as proof of capability, not as a personal CV. Projects involving sensitive data are presented anonymised unless explicitly authorised. - **Operational systems.** Modular platforms, people management, projects, activities, permissions, administration and reporting. - **Data and indicators.** Data models, reporting views, dashboards, social impact, BI, R/Shiny, React and governed spreadsheets. - **Automation.** Python pipelines, OCR, PDFs, invoices, receipts, payslips, surveys, CSV, Excel, rules and human review. - **Non-profit sector.** Extensive experience with foundations, associations, social projects, small teams, justification of activity, indicators and reporting for funders. - **IT governance.** Backups, RLS, roles, deployments, domains, Cloudflare, Supabase, Firebase, Linux and operational documentation. - **IT leadership.** A Fractional IT Director function for organisations that need senior judgement without creating a full in-house post. - **Applied AI.** Use of AI for diagnostics, documentation, classification, extraction, prototyping and development support, always with human control. Contact: [contacta@enter20.com](https://www.enter20.commailto:contacta@enter20.com) · [Contact form](https://www.enter20.com/en/contact/) · [Diagnostic questionnaire](https://evaluo.enter20.com) --- ## Contact > Contact enter 2.0 about AI and data diagnostics, dashboards, operational tools, automation and IT governance. - URL: https://www.enter20.com/en/contact/ - Español: https://www.enter20.com/contacto/ - enter 2.0 — Practical AI, governed data, dashboards, automation and information systems for organisations that need to make better decisions. The most useful way to start is to describe which information is scattered, which decision is hard to make or which repetitive task takes up too much time. Public email: [contacta@enter20.com](https://www.enter20.commailto:contacta@enter20.com) - No fixed prices are published. The scope depends on the diagnostic, the risk, the data available and the organisation's internal capacity. - Cases involving sensitive information are handled confidentially and are anonymised by default if used as a public reference. - Every request is read and answered by a person. ### Prefer a detailed diagnostic? If you would like to explain in detail how your organisation works (processes, data, tools, AI, governance), you can start our structured diagnostic questionnaire in under 10 minutes. [Start the questionnaire](https://evaluo.enter20.com) --- ## Organisational memory: keeping knowledge in the company when the AI tool changes > How to turn procedures, definitions and decisions into reviewed cards with sources and validity dates that any AI tool can use and the company can keep. - URL: https://www.enter20.com/en/blog/organisational-memory-keep-knowledge-when-changing-ai-tools/ - Español: https://www.enter20.com/blog/memoria-organizativa-conocimiento-se-quede-en-la-empresa-aunque-cambie-herramienta-ia/ - Updated: 9 November 2026 - enter 2.0 — Practical AI, governed data, dashboards, automation and information systems for organisations that need to make better decisions. - Published: 2026-11-09 - Updated: 2026-11-09 - Topic: Knowledge and context for AI - Tags: AI, knowledge, context, documentation, portability - For: Senior management, heads of department, IT and those responsible for internal documentation - The enter 2.0 team ### Short answer Every new joiner and every change of tool means explaining all over again how the organisation works. If that knowledge were curated as the organisation's own cards, in plain text with sources, an owner, a version and a review date, any AI assistant could use it and the organisation could take it along when it changes vendor. The hard part is not the format. It is resolving contradictions between documents, deciding who approves each card and withdrawing from use anything that has expired or depends on a source that has changed. ### Key points - If an AI assistant's context is built inside a vendor's tool, it is lost or has to be rebuilt when the organisation changes vendor. - Curating knowledge as the organisation's own plain-text cards, with sources, owner, version and review date, makes it reviewable and portable across AI tools. - The hard part is not the format but resolving contradictions between documents, deciding who approves each card and withdrawing whatever has expired. - An unapproved draft should not feed answers, and permissions must be applied before building the context an assistant receives, not afterwards. - It is best to start with one well-defined process, validate the first cards with the people who apply them every day and then extend by department. ### Context should not live inside the tool AI assistants give better answers when they know the organisation's definitions, procedures and decisions. The usual approach is to build that context inside the tool: custom instructions, uploaded documents, the assistant's own memory. When you change vendor, all of that is lost or has to be rebuilt. A library of Markdown knowledge cards with metadata is independent of the tool. There are open formats still evolving, such as the Open Knowledge Format, that propose conventions for provenance, verification and validity; they are useful as an exchange format, not as a guarantee of compatibility with any given product. ### A card is a reviewed decision Two procedures may say different things about the same deadline: one mentions thirty days and another, more recent one, forty-five. A model can propose a draft that reflects both, but the contradiction is resolved by someone in the relevant department, who corrects the text, records the reason and approves it. The approval records owner, date and version. Each card keeps its sources and a history. An unapproved draft should not feed answers, and a card whose source changes should stop being distributed until it has been checked and approved again. Validity expires: the review cadence is agreed with each department. ### Each team receives its own context Not everyone should receive every card. Finance needs the margin criteria; sales, the renewal terms; operations, its procedures. Permissions must be applied before building the context an assistant receives, not afterwards. A card's metadata describe its provenance and validity, but they are neither an access control nor a signature of authenticity. An exported package is not encrypted: accounts, permissions, backups and the exit procedure remain part of the implementation, not of the format. ### Start with a well-defined process Converting all the documentation in one go usually fails. It is more useful to choose a specific process, select its authorised sources, curate the first cards, validate them with the people who apply them every day and put them into use. The work is then extended department by department, with agreed owners and reviews. The result is a shared set of criteria across departments and tools, onboarding and handovers backed by reviewed knowledge, and the ability to change AI vendor without starting from scratch. It is organisational work with technical support, not the other way round. ### Frequently asked questions #### How can we avoid losing the context we have given an AI assistant if we change vendor? Keep that context out of the tool itself: custom instructions, uploaded documents and the assistant's own memory are lost or have to be rebuilt when you change vendor. The alternative is a library of the organisation's own Markdown cards with metadata, independent of any tool. Each card records its sources, owner, version and review date, so any AI assistant could use it. #### What should we do when two internal documents say different things about the same procedure? The contradiction is resolved by someone in the relevant department, not by the model. A model can propose a draft that reflects both versions, but that person corrects the text, records the reason and approves the card. The approval records owner, date and version, and the card keeps its sources and a history. If a source changes, the card should stop being distributed until it has been checked and approved again. #### How do we control which internal knowledge each team receives when using an AI assistant? Permissions must be applied before building the context the assistant receives, not afterwards, because not everyone should receive every card: finance, sales and operations need different things. A card's metadata describe its provenance and validity, but they are neither an access control nor a signature of authenticity. Accounts, permissions, backups and the exit procedure are part of the implementation, not of the format. #### Where should we start when documenting the organisation's knowledge for use with AI? With one well-defined process: converting all the documentation in one go usually fails. Choose a specific process, select its authorised sources, curate the first cards, validate them with the people who apply them every day and put them into use. Then extend department by department, with agreed owners and reviews. ### Connected services and cases - [AI and data diagnostic](https://www.enter20.com/en/services/ai-data-diagnostic/) - [Document and data automation](https://www.enter20.com/en/services/document-data-automation/) - [Fractional IT Director](https://www.enter20.com/en/services/fractional-it-director/) - [Modular operations platform for a foundation](https://www.enter20.com/en/work/foundation-operations-platform/) - [Document automation with Python and human review](https://www.enter20.com/en/work/python-document-automation/) --- ## Working with AI assistants without losing the thread: rules and memory in the repository > A method for traceable development with AI assistants: one set of rules, versioned memory, session prompts, handovers and a guard before every commit. - URL: https://www.enter20.com/en/blog/working-with-ai-assistants-rules-memory-in-repository/ - Español: https://www.enter20.com/blog/trabajar-con-asistentes-de-ia-sin-perder-el-hilo-reglas-memoria-repositorio/ - Updated: 23 October 2026 - enter 2.0 — Practical AI, governed data, dashboards, automation and information systems for organisations that need to make better decisions. - Published: 2026-10-23 - Updated: 2026-10-23 - Topic: Working method with AI - Tags: AI, coding assistants, method, documentation, traceability - For: IT managers, small technical teams and those who commission AI-assisted development - The enter 2.0 team ### Short answer An AI assistant that writes code is only as reliable as the context it receives. If the project's rules and status live in the repository, versioned alongside the code, any assistant or person can start where the previous one left off, and every change leaves a trail. The method fits in a handful of files: a document of binding rules, a lightweight memory folder, three session prompts (start, close and handover) and a guard that runs before every commit. ### Key points - If the project's rules and status live in the repository, versioned alongside the code, any assistant or person can continue where the previous one left off. - There should be a single document of binding rules, with each tool's instructions file simply pointing to it, so that there are never two versions of the truth. - Shared memory should be deliberately lightweight and size-limited, because a memory that grows unchecked stops being read. - A handover note with the task, the work done, the work half-finished, the exact next step and what was not verified lets anyone resume without reconstructing anything. - A guard before every commit checks that private material is still ignored and that nothing looks like a secret; if it fails, there is no commit. ### A single source of rules Every tool has its own instructions file, and it is tempting to maintain several versions. It is better to have a single rules document and for each tool's file simply to point to it. That way there are never two versions of the truth about what may and may not be done. Useful rules are concrete: where work happens and where it does not, which data is never opened, which actions require a person's approval (deploying, changing a secret, touching DNS, writing to someone), how status is reported and which checks come before a commit. ### Deliberately lightweight memory Shared memory needs a few files with clear purposes: the current objective and status, the system as it stands today, procedures, outstanding work, lasting decisions with their dates and a log of what was done in each session. Anything superseded is archived so that each session starts by reading very little. Setting size limits on those files, and having the guard fail when they are exceeded, forces summarising and archiving. A memory that grows unchecked stops being read, and a memory that is not read does not exist. ### Starting, closing and handing over At the start, the assistant reads the rules and the status, reports on the state of the repository and changes nothing until a person confirms. At the close, it updates the log, the outstanding work and the decisions, runs the checks and prepares the commit. Both routines are written once and shared across tools. The handover is the piece that is usually missing: a dated note with the task, what has been done, what is half-finished (with the files), the exact next step and what was not verified. With that note and a commit marked as work in progress, another assistant, from another vendor, or the same person the next day, can pick up the work without reconstructing anything. ### A guard before every commit and honest status words A script that checks that private material is still ignored and that the staged change contains nothing that looks like a secret costs little and prevents the most expensive mistake. If it fails, there is no commit, and it states only the name of the problem, never the value. Finally, vocabulary: ‘ready’ means it works locally with the tests passing; ‘deployed’ means it is published and checked with real requests; ‘validated’ means the responsible person has walked through it on their own computer. Using three different words stops a prototype from being counted as a delivery. ### Frequently asked questions #### How do we stop a project's context getting lost when working with AI coding assistants? Keep the project's rules and status in the repository, versioned alongside the code, rather than in a tool's chat, which is lost when the tool is closed. Any assistant or person can then start where the previous one left off, and every change leaves a trail. The method fits in a handful of files: a document of binding rules, a lightweight memory folder, three session prompts (start, close and handover) and a guard that runs before every commit. #### What rules should we give an AI assistant that writes code in our repository? Concrete rules, gathered in a single document that each tool's instructions file points to. They should state where work happens and where it does not, which data is never opened, which actions require a person's approval (deploying, changing a secret, touching DNS or writing to someone), how status is reported and which checks come before a commit. Keeping a single source avoids two versions of the truth about what may and may not be done. #### How can another AI assistant or another person pick up a half-finished task? With a dated handover note recording the task, what has been done, what is half-finished (with the files), the exact next step and what was not verified. Together with a commit marked as work in progress, it lets another assistant, even one from another vendor, or the same person the next day, carry on without reconstructing anything. It is the piece that is usually missing. #### What is the difference between work that is ready, deployed and validated? ‘Ready’ means it works locally with the tests passing; ‘deployed’ means it is published and checked with real requests; ‘validated’ means the responsible person has walked through it on their own computer. Using three different words stops a prototype from being counted as a delivery. ### Connected services and cases - [AI and data diagnostic](https://www.enter20.com/en/services/ai-data-diagnostic/) - [Bespoke operational tools](https://www.enter20.com/en/services/bespoke-operational-tools/) - [IT governance, continuity and operations](https://www.enter20.com/en/services/it-governance-continuity/) - [Modular operations platform for a foundation](https://www.enter20.com/en/work/foundation-operations-platform/) - [Document automation with Python and human review](https://www.enter20.com/en/work/python-document-automation/) --- ## Layered security for small internal tools: identity at the edge and failing closed > Identity at the edge, services that fail closed, tunnels instead of open ports, protected forms and secrets that are never printed. - URL: https://www.enter20.com/en/blog/layered-security-internal-tools-identity-at-edge-fail-closed/ - Español: https://www.enter20.com/blog/seguridad-en-capas-herramientas-internas-identidad-en-el-borde-fallar-cerrado/ - Updated: 6 October 2026 - enter 2.0 — Practical AI, governed data, dashboards, automation and information systems for organisations that need to make better decisions. - Published: 2026-10-06 - Updated: 2026-10-06 - Topic: Security of internal tools - Tags: security, Zero Trust, internal tools, identity, secrets - For: IT managers, senior management and those who commission internal tools - The enter 2.0 team ### Short answer No security layer should be trusted on its own. If one fails or is misconfigured, the next one must still block the way. For a small internal tool, that means identity before anything can be reached, a service that re-checks the session on every request, and data with its own permissions. The most useful principle is to fail closed: if configuration is missing, the service serves nothing. A visible error is preferable to a tool left open without anyone knowing. ### Key points - No security layer should be trusted on its own: if one fails or is misconfigured, the next one must still block the way. - A small internal tool does not need a VPN: a one-time code sent by email and a list of authorised people are enough to handle entry. - The service should check the session on every request, keep its own list of permitted email addresses and fail closed when configuration is missing. - Office systems can be published through an outbound connection to the network edge, without opening any router ports and always with identity in front. - Documentation, logs and conversations with AI assistants should show a secret's name, never its value. ### Identity before anything can be reached A small team does not need passwords that have to be remembered and can be leaked. A one-time code sent by email and a policy listing the authorised people are enough to handle entry to a private tool, with no VPN and nothing to install. Behind that door, the service itself should check the session token on every request: algorithm, issuer, audience, expiry, email and signature. It should also keep its own list of permitted email addresses, so that if the access policy is widened by mistake, the tool stays closed. ### The same error for every failure A forged token, an expired one and one with no email should all receive the same response, without explaining which check failed. Saying ‘the token has expired’ helps an attacker refine their approach; saying ‘sign in again’ is enough for the person using the tool. If the service does not have its verification parameters configured, it must respond that access is not configured and serve nothing, even if the token is valid. An incomplete deployment must never be an open deployment. ### Tunnels, not open ports Whatever lives in the office (a database, a machine that reads documents) can be published through an outbound connection to the network edge, without opening any port on the router. Identity always comes first, even for a quick test. For public forms, a bot check without annoying captchas, a honeypot field and storing the IP address only as a hash reduce the noise without asking anything of the person filling them in. And a strict content security policy in the browser stops a third-party script from slipping into the page. ### Secrets by name only In documentation, in conversations with AI assistants and in logs, the name of a secret should appear, never its value. The value lives in the service's secrets manager and in a local file that version control ignores. One deploy key per repository, a guard that checks every commit for anything that looks like a secret, and a short list of actions that require human approval (deploying, changing a secret, touching the access configuration or DNS) complete a hygiene routine that costs little and prevents incidents. ### Frequently asked questions #### How can I secure access to a small internal tool without setting up a VPN? Put identity in front of everything: a one-time code sent by email and a policy listing the authorised people, with no passwords and nothing to install. Behind that, the service itself should check the session token on every request (algorithm, issuer, audience, expiry, email and signature) and keep its own list of permitted email addresses. That way, if the access policy is widened by mistake, the tool stays closed. #### What does it mean for an internal tool to ‘fail closed’? It means that if configuration is missing, the service serves nothing. If its verification parameters are not configured, it must respond that access is not configured, even if the token is valid. A visible error is preferable to a tool left open without anyone knowing: an incomplete deployment must never be an open deployment. #### What error message should an internal tool show when an access check fails? The same one for every failure, without explaining which check failed. A forged token, an expired token and a token with no email should all receive the same response. Saying ‘the token has expired’ helps an attacker refine their approach, whereas ‘sign in again’ is enough for the person using the tool. #### What basic measures stop an internal tool's keys and secrets from leaking? Documentation, logs and conversations with AI assistants should show a secret's name, never its value, which lives in the service's secrets manager and in a local file ignored by version control. Add one deploy key per repository and a guard that checks every commit for anything that looks like a secret. A short list of actions that require human approval, such as deploying, changing a secret or touching the access configuration or DNS, completes a hygiene routine that costs little and prevents incidents. ### Connected services and cases - [IT governance, continuity and operations](https://www.enter20.com/en/services/it-governance-continuity/) - [Fractional IT Director](https://www.enter20.com/en/services/fractional-it-director/) - [Bespoke operational tools](https://www.enter20.com/en/services/bespoke-operational-tools/) - [Modular operations platform for a foundation](https://www.enter20.com/en/work/foundation-operations-platform/) - [Survey pipeline and qualitative analysis](https://www.enter20.com/en/work/survey-qualitative-analysis/) --- ## From PDF to reviewed data: fingerprint, evidence and review queue > Designing document data extraction with fingerprints for duplicates, per-field evidence, immutable originals and human review that does not slow work. - URL: https://www.enter20.com/en/blog/from-pdf-to-reviewed-data-fingerprint-evidence-review-queue/ - Español: https://www.enter20.com/blog/del-pdf-al-dato-revisado-huella-evidencia-cola-de-revision/ - Updated: 18 September 2026 - enter 2.0 — Practical AI, governed data, dashboards, automation and information systems for organisations that need to make better decisions. - Published: 2026-09-18 - Updated: 2026-09-18 - Topic: Document automation - Tags: documents, automation, OCR, evidence, human review - For: Administration, operations managers and IT - The enter 2.0 team ### Short answer A reliable document workflow does not start with the model that reads the PDF. It starts by identifying each document with a fingerprint, keeping the original untouched, storing alongside each extracted data point the evidence of where it came from and letting a person approve what matters. With those four pieces in place, it makes no difference whether extraction is done by rules, OCR or a language model: the result can be checked, corrected and explained. ### Key points - A reliable document workflow rests on four pieces: a fingerprint for each document, an untouched original, evidence alongside each extracted data point and human approval of what matters. - A cryptographic fingerprint of the content detects duplicates even if the file name or folder changes, and proves that the approved document is the one received. - If reviewing a data point highlights the fragment of the PDF it comes from, review takes seconds and errors become visible. - It is best to start with deterministic rules, which are cheap and predictable, and reserve an AI model for the documents the rules cannot resolve. - When a rule is weak, the system should say so rather than treat the result as correct: an honest warning is worth more than a silent match. ### The fingerprint stops you paying twice The same document arrives through five routes: email, the supplier's portal, a scan, forwarded by a colleague, downloaded again. If the system calculates a cryptographic fingerprint of the content, the duplicate is detected even if the file name or folder changes. The fingerprint also prevents the same tender document or call for proposals from being processed twice, and makes it possible to prove later that the approved document is exactly the one that was received. ### The original is never touched When a document is approved, it is best to archive a copy with a standardised name (date, supplier, number) and leave the original intact. An inventory of a file server should be mounted read-only: classifying and extracting must not be able to modify or delete anything. That immutability simplifies audits and grant reporting: the document always exists exactly as it arrived, and the standardised copy is a convenience, not the source. ### Every data point with its evidence An amount, a date or a tax ID extracted without any indication of which part of the document it came from is hard to review. If hovering over the data point highlights the fragment of the PDF it comes from, review takes seconds and errors become visible. It is best to start with deterministic rules, which are cheap and predictable, and to reserve an AI model for the documents the rules cannot resolve. If the model runs outside the office, it should be switched off by default and enabled document by document, with that decision recorded. ### Review that does not slow things down Human review does not have to mean reading everything. It can be an exceptions inbox: whatever meets the rules goes through flagged as a proposal, and whatever does not match the expected format, or fails twice, lands in "review by hand". Every approval records who approved it and when. When a rule is weak, for example when matching a payslip to a bank transfer by amount and approximate date, the system should say so instead of taking the result as correct. An honest warning is worth more than a silent match. ### Frequently asked questions #### How do I avoid processing or paying the same invoice twice when it arrives through different channels? By calculating a cryptographic fingerprint of each document's content: the duplicate is then detected even if the file name or folder changes. The same fingerprint prevents a tender document or call for proposals from being processed twice and makes it possible to prove later that the approved document is exactly the one received. #### Should I use AI or rules to extract data from invoices and payslips? It is best to start with deterministic rules, which are cheap and predictable, and reserve an AI model for the documents the rules cannot resolve. If the model runs outside the office, it should be switched off by default and enabled document by document, with that decision recorded. With a fingerprint, an untouched original, evidence and human review, the result can be checked and corrected whatever the extraction method. #### How can data extracted from PDFs be reviewed without reading everything? With an exceptions inbox: whatever meets the rules goes through flagged as a proposal, and whatever does not match the expected format, or fails twice, is set aside for manual review. If each data point shows the fragment of the PDF it comes from, checking takes seconds. Every approval records who made it and when. #### Why keep the original document if we already have the extracted data? Because an untouched original simplifies audits and grant reporting: the document always exists exactly as it arrived. On approval, a copy can be archived with a standardised name (date, supplier, number), but that copy is a convenience, not the source. For the same reason, an inventory of a file server should be mounted read-only. ### Connected services and cases - [Document and data automation](https://www.enter20.com/en/services/document-data-automation/) - [Bespoke operational tools](https://www.enter20.com/en/services/bespoke-operational-tools/) - [Document automation with Python and human review](https://www.enter20.com/en/work/python-document-automation/) --- ## A backup is only as good as its restore > Layered backups, monthly test restores, runbooks with rollback and recorded decisions for continuity in a small organisation. - URL: https://www.enter20.com/en/blog/backup-only-as-good-as-its-restore/ - Español: https://www.enter20.com/blog/una-copia-de-seguridad-vale-lo-que-vale-su-restauracion/ - Updated: 31 August 2026 - enter 2.0 — Practical AI, governed data, dashboards, automation and information systems for organisations that need to make better decisions. - Published: 2026-08-31 - Updated: 2026-08-31 - Topic: IT continuity and operations - Tags: backups, continuity, IT operations, runbooks, decisions - For: Senior management, IT managers and administrative staff in small organisations - The enter 2.0 team ### Short answer A backup is not verified by reading its log, but by restoring it. Some backups are reported as fine by the system for months and then, when the moment comes, cannot take you back to the point you need. Continuity is built in layers: a fast local backup, a backup that a central machine ‘pulls’ and that the machine being backed up cannot delete, and an off-site backup with a restricted key. And a test restore in the calendar. ### Key points - A backup is verified by restoring it, not by reading its log: some backups the system reports as fine cannot take you back to the point you need. - A large disk, a file server or a synchronised folder gives a sense of security that does not survive hardware failure, accidental deletion or an encryption attack. - Continuity is built in layers: a fast local backup, a backup that a central machine takes and the backed-up machine cannot delete, and another off-site. - Layer zero is being able to rebuild the machine from scratch with versioned procedures and configuration; if that depends on one person's memory, it is not a layer. - A weekly integrity check and a monthly test restore, with the date and result recorded, turn the backup from an act of faith into a fact. ### A large disk is not a backup Keeping data on a high-capacity disk, on a file server or in a synchronised folder gives a sense of security that does not survive a hardware failure, an accidental deletion or an attack that encrypts the machine. When a disk starts to fail, the right thing to do is stop writing to it and mount it read-only to rescue whatever can be saved. An attack that encrypts a machine also encrypts everything that machine can reach. That is why the backup that matters is the one the machine cannot touch: a central station connects and takes the encrypted backup away, and the office machine does not hold that station's credentials. ### Layers, and what happens if One way to explain backups to non-technical people is through scenarios. A folder is deleted by mistake: it is recovered from the previous day's local backup. The disk fails: the machine is reinstalled from the configuration repository and the backup from the central station is restored. Fire or theft: a new machine, a rebuild and the data from the cloud in a European region. Layer zero is being able to rebuild the machine from scratch using versioned procedures and configuration. If that depends on one person's memory, it is not a layer. ### Test restores, and failures reported as they are A weekly integrity check and a monthly test restore, with the date and result recorded, change the conversation: the backup stops being an act of faith and becomes a fact. The trial runs uncover errors that the log does not show, such as backups marked as failed because a file changed during the backup even though the archive was created correctly. Distinguishing warnings from failures, and alerting only on real failures, keeps the team from tuning out the alerts. And keeping the previous version of a script before fixing it makes it possible to roll back if the fix causes problems. ### Written decisions and procedures with a way back Every lasting decision deserves a short note: context, decision, exceptions and consequences. For example, that only configuration goes off-site until the client decides about their data, or that the cloud is used only with recorded authorisation. Years later, that note explains why things are the way they are. A procedure is not ready unless it says how it is verified and how it is reversed. Objective, command, verification and rollback fit on half a page, and that half page is the difference between an operation and a gamble. ### Frequently asked questions #### How do I know whether a backup actually works? By restoring it, not by reading its log. Some backups are reported as fine by the system for months and then, when the moment comes, cannot take you back to the point you need. A weekly integrity check and a monthly test restore, with the date and result recorded, turn the backup from an act of faith into a fact. Trial restores uncover errors that the log does not show. #### How can we protect our backups from an attack that encrypts our computers? Keep the backup that matters out of reach of the machine being backed up, because an attack that encrypts a machine also encrypts everything that machine can reach. A central station connects and takes the encrypted backup away, and the office machine does not hold that station's credentials. That layer sits alongside a fast local backup and an off-site backup with a restricted key. #### How do we recover data if a folder is deleted by mistake or a disk fails? Each scenario is covered by a different layer. A folder deleted by mistake is recovered from the previous day's local backup; if the disk fails, the machine is reinstalled from the configuration repository and the backup is restored from the central station. After a fire or theft, you start with a new machine, rebuild it and recover the data from the cloud. If a disk starts to fail, the right thing to do is stop writing to it and mount it read-only to rescue whatever can be saved. #### What should an IT operations procedure include to be reliable? Objective, command, verification and rollback: a procedure is not ready unless it says how it is verified and how it is reversed. All of that fits on half a page, and that half page is the difference between an operation and a gamble. In addition, every lasting decision deserves a short note with context, decision, exceptions and consequences, which years later explains why things are the way they are. ### Connected services and cases - [IT governance, continuity and operations](https://www.enter20.com/en/services/it-governance-continuity/) - [Fractional IT Director](https://www.enter20.com/en/services/fractional-it-director/) - [Modular operations platform for a foundation](https://www.enter20.com/en/work/foundation-operations-platform/) --- ## Permissions live in the database, not on the screen > Why an internal tool's permissions, validations and audit trail must be enforced in the database and not only in the interface. - URL: https://www.enter20.com/en/blog/permissions-live-in-the-database-not-the-screen/ - Español: https://www.enter20.com/blog/los-permisos-viven-en-la-base-de-datos-no-en-la-pantalla/ - Updated: 13 August 2026 - enter 2.0 — Practical AI, governed data, dashboards, automation and information systems for organisations that need to make better decisions. - Published: 2026-08-13 - Updated: 2026-08-13 - Topic: Internal tools and permissions - Tags: permissions, databases, internal tools, security, audit - For: IT managers, operations directors and those who commission internal tools - The enter 2.0 team ### Short answer An access rule that exists only in the interface is a suggestion. If someone calls the API directly, opens another screen or a bug lets a query through, the rule disappears. The rules that matter must be enforced in the database. The same applies to validations and auditing: ensuring that a person cannot be allocated at 120%, that an old clock-in record cannot be edited or that every change leaves a trace are guarantees best applied where the data lives. ### Key points - An access rule that exists only in the interface is a suggestion: a direct API call, another screen or a bug is enough to bypass it. - With row-level policies, the database filters every query by who is asking, and data that does not belong to a user is not hidden: it is simply not there. - Business rules must be validated in the data, because an import, a script or a new screen will bypass rules that only the form enforces. - A useful practice is for the application to write only through functions with narrowly scoped permissions, which record the change and the audit entry in the same transaction. - Closing, archiving or deactivating instead of deleting preserves the history, keeps reports consistent and makes it possible to explain decisions. ### Each department sees only its own data In a tool shared by several departments, or by several companies on the same platform, isolation is achieved with row-level policies: the database filters every query according to who is asking. Maintenance sees its own issues, management sees all of them, and nobody has to remember to add a filter on every screen. The practical effect shows when you switch user: whatever does not belong to that user ceases to exist for that session. It is not hidden; it is not there. That difference is what protects you when the interface has a bug. ### Write only through functions A useful practice is for the application not to write directly to the tables, but through functions with narrowly scoped permissions. Each function does one thing, checks what it needs to check and records, in the same transaction, the change, the audit entry and, where appropriate, an automatic comment. With a version number on every record, two people do not overwrite each other: if someone saves over an old version, the operation fails and they are shown the other person's change. This is simpler than locking records and avoids silent data loss. ### Validate in the data, not in the form Making sure a person does not exceed 100% allocation in overlapping periods, that a PIN is locked after five attempts or that an old clock-in record cannot be modified: these are business rules. If only the form enforces them, an import, a script or a new screen will bypass them without meaning to. The same goes for what must not leave the system: the cost price in a catalogue must be removed in the public API, not just hidden on screen, and an internal questionnaire score should never be sent to the client's browser. ### Never delete: close or deactivate Deleting destroys the history and, with it, the ability to explain a decision. Closing, archiving or deactivating preserves what happened and keeps reports consistent. Closing an issue can require writing down what was learned: it costs little and leaves a record behind. These decisions do not require a large platform. A well-configured relational database, functions with narrowly scoped permissions and a mandatory backup before every migration are enough for a small tool to remain reliable for years. ### Frequently asked questions #### Is hiding data in the interface enough to ensure each department sees only its own information? No. An access rule that exists only on screen disappears if someone calls the API directly, opens another screen or a bug lets a query through. Isolation is achieved with row-level policies in the database, which filter every query according to who is asking. That way, data that does not belong to a user is not hidden: it does not exist for their session. #### How do I stop two people overwriting each other's changes in an internal tool? With a version number on every record. If someone saves over an old version, the operation fails and they are shown the other person's change. This is simpler than locking records and avoids silent data loss. #### Should business validations be enforced in the form or in the database? In the database. Rules such as a person not exceeding 100% allocation in overlapping periods, a PIN locking after five attempts or an old clock-in record not being editable are bypassed unintentionally if only the form enforces them: an import, a script or a new screen is enough. The same applies to data that must not leave the system, such as a catalogue's cost price in a public API. #### Do I need a large platform for an internal tool to be reliable? No. Validating in the data, applying row-level permissions or closing records instead of deleting them does not require a large platform. A well-configured relational database, functions with narrowly scoped permissions and a mandatory backup before every migration are enough for a small tool to remain reliable for years. ### Connected services and cases - [Bespoke operational tools](https://www.enter20.com/en/services/bespoke-operational-tools/) - [IT governance, continuity and operations](https://www.enter20.com/en/services/it-governance-continuity/) - [Fractional IT Director](https://www.enter20.com/en/services/fractional-it-director/) - [Modular operations platform for a foundation](https://www.enter20.com/en/work/foundation-operations-platform/) --- ## AI proposes, a person decides: how to inventory AI use across your tools > How to document, for each tool, what AI does, what it never does, where it runs and who reviews it, with criteria for SMEs and social organisations. - URL: https://www.enter20.com/en/blog/ai-proposes-a-person-decides-inventory-ai-use/ - Español: https://www.enter20.com/blog/la-ia-propone-una-persona-decide-inventariar-uso-ia-herramientas/ - Updated: 26 July 2026 - enter 2.0 — Practical AI, governed data, dashboards, automation and information systems for organisations that need to make better decisions. - Published: 2026-07-26 - Updated: 2026-07-26 - Topic: AI governance - Tags: AI, governance, human review, vendors, EU AI Act - For: General management, IT managers and department heads - The enter 2.0 team ### Short answer Governing AI in a small organisation does not require a committee or a fifty-page document. It requires an honest table: for each tool, what the AI does, what it never does, where it runs and which person reviews what it proposes. That table clarifies more than any generic policy. It shows that in some tools the AI only transcribes, in others it prepares a record that someone validates and in others, deliberately, there is no AI. ### Key points - Governing AI in a small organisation requires an honest table: for each tool, what the AI does, what it never does, where it runs and who reviews it. - Writing down what the AI never does, such as scoring applications or replying to a client, stops its scope from growing without anyone deciding it. - Whatever is handed to an external model leaves the organisation, and removing the name is not anonymisation: sector, size, dates and job titles also identify people. - Every model output should arrive flagged as a proposal, with its evidence, until a person accepts, corrects or rejects it, with who and when recorded. - Sometimes the right answer is not to use AI, as with a whistleblowing channel, where trust rests on a person handling the case. ### Four columns that change everything The first column describes the specific task: transcribing a CV into a record, extracting the purpose, deadline and amount from a call for proposals, proposing a classification for a document. The narrower the task, the easier it is to review and to replace. The second sets out what the AI never does: score applications, decide whether the organisation enters a tender, reply to a client, promise results. Writing this down stops the scope from growing without anyone deciding it. The other two columns, where it runs and who reviews, turn the table into a risk map. ### Where it runs matters as much as what it does Whatever is handed to an external model leaves the organisation. That is why it is worth distinguishing between a model running on the organisation's own hardware, one running in a vendor's account under contract and an external one that only receives public text, such as that of an official call for proposals. A layer of your own between the application and the model makes it possible to switch vendor without rewriting the product, and logging each call with its cost tells you how much it costs and when it fails. Removing the name is not anonymisation. Sector, size, dates and job titles identify someone just as surely as a surname. Minimising what is sent and aggregating data with minimum thresholds offers more protection than superficial deletion. ### Flag the proposal until someone reviews it Everything that comes out of a model should arrive flagged as a proposal, with its evidence alongside: the fragment of the document from which an amount was extracted, the paragraph a date came from. The flag disappears when a person accepts, corrects or rejects it, and who did so and when is recorded. If the output does not match the expected format, a retry is advisable and, if it fails again, a manual review queue. A system that falls back to a person is more reliable than one that improvises. ### When the right answer is not to use AI A whistleblowing channel should not depend on a model for anything: the trust of the person making a report rests on a human being handling the case. A tool that reconstructs billable hours from the calendar can classify with rules and keywords, which are predictable and auditable. Recruitment tools deserve special attention: the EU AI Act classifies systems that filter or evaluate applications as high-risk. Designing the tool so that the AI only transcribes, without scoring, ranking or extracting age, sex or nationality, is a design decision that must be documented and does not replace each organisation's own legal analysis. ### Frequently asked questions #### How do I document AI use across my organisation's tools without setting up a committee? With a four-column table for each tool: the specific task the AI performs, what it never does, where it runs and which person reviews what it proposes. That table clarifies more than a generic policy and works as a risk map. It shows, for example, that in some tools the AI only transcribes, in others it prepares a record that someone validates and in others, deliberately, there is no AI. #### Is removing names enough before sending data to an external AI model? No. Removing the name is not anonymisation: sector, size, dates and job titles identify someone just as surely as a surname. Minimising what is sent and aggregating data with minimum thresholds offers more protection than superficial deletion. It also matters whether the model runs on the organisation's own hardware, in a vendor's account under contract or in an external service that only receives public text. #### Can a recruitment tool use AI to filter job applications? This case requires special attention: the EU AI Act classifies systems that filter or evaluate applications as high-risk. One possible design decision is for the AI only to transcribe, without scoring, ranking or extracting age, sex or nationality. That decision must be documented and does not replace each organisation's own legal analysis. #### What should the system do when the AI returns output in the wrong format? Retry once and, if it fails again, send the case to a manual review queue. A system that falls back to a person is more reliable than one that improvises. In any case, everything a model produces should arrive flagged as a proposal until a person accepts, corrects or rejects it. ### Connected services and cases - [AI and data diagnostic](https://www.enter20.com/en/services/ai-data-diagnostic/) - [IT governance, continuity and operations](https://www.enter20.com/en/services/it-governance-continuity/) - [Document automation with Python and human review](https://www.enter20.com/en/work/python-document-automation/) - [Modular operations platform for a foundation](https://www.enter20.com/en/work/foundation-operations-platform/) --- ## From cost savings to irrelevance: the danger of automating without redesigning your processes > Why applying advanced tools to outdated, disorganised processes neutralises your organisation's value and what sets it apart. - URL: https://www.enter20.com/en/blog/danger-of-automating-without-redesigning-processes/ - Español: https://www.enter20.com/blog/del-ahorro-de-costes-a-la-irrelevancia-peligro-automatizar-sin-redisenar-procesos/ - Updated: 8 July 2026 - enter 2.0 — Practical AI, governed data, dashboards, automation and information systems for organisations that need to make better decisions. - Published: 2026-07-08 - Updated: 2026-07-08 - Topic: Technology adoption and processes - Tags: automation, processes, strategy, technology - For: General management, operations managers and project coordinators - The enter 2.0 team ### Short answer In small organisations, foundations and SMEs, using advanced tools to do faster what is already done manually simply moves the original disorder onto a faster digital platform. Building the strategy around cheap execution of common tasks creates a silent problem: the complete loss of differentiation and of real value in how the organisation is managed. ### Key points - Automating inefficient tasks without redesigning the processes simply moves the original disorder onto a faster digital platform. - Delegating routine tasks to low-cost tools is sensible; the mistake is believing that optimising that routine layer amounts to the whole digital transformation. - Handling legacy processes with the same generic instructions as competitors makes an organisation's impact homogeneous and strips away its differentiation. - As with electricity in factories, the productivity leap comes from redesigning the entire workflow, not from simply changing the engine. - Real transformation rests on internal pillars rather than generic external tools: the organisation's own memory, clean data and a culture of experimentation. ### The tactical filter mistake It is right to delegate routine, mechanical problems (such as processing standard texts or structuring repetitive data) to low-cost tools in order to keep the budget under control. The mistake arises when management considers that optimising that routine layer amounts to the entire digital transformation. If you use the same generic instructions as your competitors to handle legacy processes, your organisational impact becomes indistinguishable from theirs. ### The lesson from history: redesign the structure When electricity reached factories, productivity did not improve for decades because managers merely replaced the central steam engine with an electric one, keeping the old layout of the machinery. The real leap came when the entire workflow was redesigned around the new, independent capabilities. Automating your old tasks with today's technologies is merely "swapping the steam engine". Real competitive advantage appears when you design a process architecture that was previously unfeasible because of constraints on time or staff, approaching information from an entirely new perspective. ### Building value: context and autonomy For an organisation to achieve real transformation, it must rest on internal pillars that do not depend on generic external tools: Its own memory and clean data: the value lies not in the software but in how it connects to your internal methodologies and databases to create a unique operational anchor. A culture of experimentation: giving those who best understand the day-to-day context the minimum resources to test solutions without being held back by bureaucratic red tape. The market has already democratised execution muscle. The real challenge for leaders and consultants is no longer to automate the past, but to bring the judgement needed to redefine which processes are worth carrying out. ### Frequently asked questions #### Is automating our manual tasks enough to transform the organisation digitally? No. Delegating routine, mechanical tasks to low-cost tools helps keep the budget under control, but optimising that layer is not the whole digital transformation. Doing faster what is already done by hand simply moves the original disorder onto a faster platform. Value appears when the process architecture is redesigned. #### What is the risk of handling our processes with the same generic tools our competitors use? The risk is that the organisation's impact becomes homogeneous. If legacy processes are handled with the same generic instructions as everyone else, execution may be cheaper, but differentiation and real value in management are lost. The market has already democratised execution; the real challenge is to bring the judgement needed to redefine which processes are worth carrying out. #### What does the arrival of electricity in factories teach us about automation today? That changing the engine is not enough. When managers replaced the central steam engine with an electric one and kept the old layout of the machinery, productivity did not improve for decades. The leap came when the entire workflow was redesigned around the new capabilities. Automating old tasks with today's technologies is the equivalent of changing only the engine. #### What should an SME or foundation rely on to achieve real transformation? On internal pillars that do not depend on generic external tools. First, its own memory and clean data: the value lies not in the software but in how it connects to internal methodologies and databases. Second, a culture of experimentation that gives those who know the day-to-day work best the minimum resources to test solutions without bureaucratic obstacles. ### Connected services and cases - [AI and data diagnostic](https://www.enter20.com/en/services/ai-data-diagnostic/) - [IT governance, continuity and operations](https://www.enter20.com/en/services/it-governance-continuity/) - [Document and data automation](https://www.enter20.com/en/services/document-data-automation/) - [Document automation with Python and human review](https://www.enter20.com/en/work/python-document-automation/) - [Modular operations platform for a foundation](https://www.enter20.com/en/work/foundation-operations-platform/) --- ## Why AI projects fail when the data model is not understood > How to avoid weak AI projects by first reviewing processes, entities, permissions, source data and indicators. - URL: https://www.enter20.com/en/blog/why-ai-projects-fail-without-understanding-data-model/ - Español: https://www.enter20.com/blog/por-que-proyectos-ia-fallan-modelo-datos/ - Updated: 24 June 2026 - enter 2.0 — Practical AI, governed data, dashboards, automation and information systems for organisations that need to make better decisions. - Published: 2026-06-23 - Updated: 2026-06-24 - Topic: AI and the data model - Tags: AI, data, governance, diagnostic - For: Senior management, operations managers and IT teams - The enter 2.0 team ### Short answer An AI project fails when the model is expected to settle decisions the organisation has not yet defined: what each entity is, who may see it, which data item is the official source and which indicator counts as valid. Before automating, it is worth mapping out the operating model: people, projects, documents, statuses, roles, permissions, reporting outputs and exceptions. That map reduces risk and gives the AI a verifiable foundation to work on. ### Key points - An AI project fails when the model is expected to settle decisions the organisation has not yet defined, such as which data item is the official source or which indicator is valid. - Before automating, it is worth mapping the operating model (people, projects, documents, statuses, roles, permissions, reporting outputs and exceptions) so that AI works on a verifiable foundation. - A data model is also a model of responsibility: it makes explicit who creates records, who validates, who can see, who corrects and who decides on the output. - AI works best as a support layer, for classifying, summarising or spotting inconsistencies, and worst when it is used to cover up a lack of process. - The sign of maturity is not having lots of prompts but knowing which data can be used, within what limits, for which decision and under what human oversight. ### AI is no substitute for internal definitions Many pilots start with an attractive question: what can an assistant do with the organisation's documents, emails or spreadsheets? The useful question usually comes earlier: what does each data item mean, and who has the authority to change it? If the same person appears under different names, if a project has several codes, if dates do not mean the same thing in every department or if nobody knows which version of a spreadsheet is the right one, the AI model may produce fluent answers that are hard to defend. ### The data model is also a model of responsibility A data model is not just a table. It defines what things exist in the organisation and how they relate to one another: people, activities, case files, invoices, indicators, documents, permissions and decisions. Once those relationships are made explicit, responsibilities emerge too: who creates a record, who validates it, who can see it, who corrects it and who uses the output to make a decision. Without that layer, AI is operating in an ambiguous environment. ### Where AI fits best AI works best as a support layer: classifying documents, summarising information, spotting inconsistencies, generating drafts, helping to write transformations or suggesting labels for human review. It works less well when it is used to cover up a lack of process. If there is no agreed definition of beneficiary, project, intervention, status or outcome, AI cannot create an operational truth on its own. ### A sign of maturity A good AI diagnostic usually produces less immediate enthusiasm and better decisions. Some tasks are automated, others are redesigned and others are dropped because the risk or the cost does not pay off. The sign of maturity is not having lots of prompts. It is knowing which data can be used, within what limits, for which decision and under what human oversight. ### Frequently asked questions #### Why does an AI assistant give convincing but unreliable answers about our organisation's data? Usually because the underlying data is ambiguous. If the same person appears under different names, a project has several codes, dates mean different things in different departments or nobody knows which version of a spreadsheet is the right one, the model can produce fluent answers that are hard to defend. AI does not, on its own, fix ambiguous data, blurred responsibilities or poorly defined processes. #### What should we review before launching an AI project on our organisation's data? First map out the operating model: people, projects, documents, statuses, roles, permissions, reporting outputs and exceptions. You also need to define what each entity is, who may see it, which data item is the official source and which indicator counts as valid. That map reduces risk and gives the AI a verifiable foundation to work on. #### Which tasks is AI genuinely useful for in an organisation, and which is it not? AI works best as a support layer: classifying documents, summarising information, spotting inconsistencies, generating drafts, helping to write transformations or suggesting labels for human review. It works less well when it is used to cover up a lack of process. If there is no agreed definition of concepts such as beneficiary, project or outcome, AI cannot create an operational truth on its own. #### What should we expect from an AI diagnostic? A good AI diagnostic usually produces less immediate enthusiasm and better decisions. Some tasks are automated, others are redesigned and others are dropped because the risk or the cost does not pay off. The sign of maturity is knowing which data can be used, within what limits, for which decision and under what human oversight. ### Connected services and cases - [AI and data diagnostic](https://www.enter20.com/en/services/ai-data-diagnostic/) - [Data, indicators and dashboards](https://www.enter20.com/en/services/data-indicators-dashboards/) - [Modular operations platform for a foundation](https://www.enter20.com/en/work/foundation-operations-platform/) - [Indicators and dashboards for social monitoring](https://www.enter20.com/en/work/social-impact-dashboards/) --- ## From Excel chaos to useful indicators for foundations and SMEs > A practical method for moving from scattered spreadsheets to reliable indicators, data models and maintainable dashboards. - URL: https://www.enter20.com/en/blog/from-excel-chaos-to-useful-indicators/ - Español: https://www.enter20.com/blog/del-caos-de-excel-a-indicadores-utiles-fundaciones-pymes/ - Updated: 24 March 2026 - enter 2.0 — Practical AI, governed data, dashboards, automation and information systems for organisations that need to make better decisions. - Published: 2026-03-24 - Updated: 2026-03-24 - Topic: Indicators and reporting - Tags: Excel, indicators, foundations, SMEs, dashboards - For: Senior management, programme coordination and administration - The enter 2.0 team ### Short answer Moving from Excel to useful indicators does not start with buying a dashboard. It starts with agreeing definitions, official sources, who is responsible for updates and rules for correcting errors. A spreadsheet can be a good tool if it is part of a clear system. It becomes fragile when it serves as database, application, report, historical archive and permissions control all at once. ### Key points - Excel is not the problem: a spreadsheet becomes fragile when it serves as database, application, report, historical archive and permissions control all at once. - Moving from Excel to useful indicators starts with agreeing definitions, official sources, update owners and error-correction rules, not with buying a dashboard. - Naming the main entities properly and deciding which fields are mandatory prevents different teams from measuring different things with the same word. - A good indicator answers a management, coordination or accountability question; if it improves no decision, the dashboard becomes decoration. - Moving away from Excel can be gradual: clean up definitions, create a common database, generate reporting views and build dashboards or tools where they add value. ### Why Excel lasts so long Excel solves immediate problems: it lets people sort, filter, correct and deliver something quickly. That is why it remains useful in foundations, associations and SMEs with small teams. The limit appears when the organisation depends on several spreadsheets held together by human memory. At that point the indicators change depending on who does the export, which filter they use or which version is circulating by email. ### The first step is naming things properly Before talking about charts, it is worth naming the main entities: people, projects, activities, case files, services, centres, dates, statuses and amounts. After that, you decide which fields are mandatory and which values are allowed. This work looks less impressive than a dashboard, but it prevents three teams from measuring different things with the same word. A useful indicator depends on a stable definition. ### Indicators that answer real questions A good indicator answers a management, coordination or accountability question: how many people are being supported, what state the projects are in, where activity is concentrated, which deadlines are being missed or what data is missing to justify a result. If nobody knows which decision an indicator improves, the dashboard becomes decoration. The visualisation should be the visible part of a more carefully built data system. ### When to move away from Excel There is no need to abandon Excel overnight. It makes sense to move away from it when there is sensitive data, several users editing, a need for permissions, history, validation, complex relationships or recurring reports. The transition can be gradual: first clean up the definitions, then create a common database, next generate reporting views and finally build dashboards or internal tools where they add value. ### Frequently asked questions #### When should my organisation stop using Excel to manage its data and indicators? It makes sense to move away from Excel when there is sensitive data, several users editing, a need for permissions, history, validation, complex relationships or recurring reports. There is no need to abandon it overnight: the transition can be gradual, starting with cleaning up definitions and creating a common database. A spreadsheet can remain useful if it is part of a clear system. #### Why do our indicators give different figures depending on who prepares the report? This happens when the organisation depends on several spreadsheets held together by human memory: indicators change depending on who exports the data, which filter they use or which version is circulating by email. The fix starts with agreeing stable definitions, official sources, update owners and rules for correcting errors. #### What needs to be done before building a dashboard from our Excel spreadsheets? Name the main entities properly (people, projects, activities, case files, services, centres, dates, statuses and amounts) and decide which fields are mandatory and which values are allowed. This work looks less impressive than a dashboard, but it stops different teams measuring different things with the same word. A useful indicator depends on a stable definition. #### How can I tell whether an indicator is useful or just decoration? An indicator is useful if it answers a real management, coordination or accountability question: how many people are being supported, what state the projects are in, which deadlines are being missed or what data is missing to justify a result. If nobody knows which decision it improves, the dashboard becomes decoration. ### Connected services and cases - [Data, indicators and dashboards](https://www.enter20.com/en/services/data-indicators-dashboards/) - [Bespoke operational tools](https://www.enter20.com/en/services/bespoke-operational-tools/) - [Indicators and dashboards for social monitoring](https://www.enter20.com/en/work/social-impact-dashboards/) --- ## What an AI adoption diagnostic should include before you buy tools > A practical list of the areas to review before implementing AI in a small or medium-sized organisation. - URL: https://www.enter20.com/en/blog/what-ai-adoption-diagnostic-should-include-before-buying-tools/ - Español: https://www.enter20.com/blog/que-debe-incluir-diagnostico-adopcion-ia-antes-comprar-herramientas/ - Updated: 18 December 2025 - enter 2.0 — Practical AI, governed data, dashboards, automation and information systems for organisations that need to make better decisions. - Published: 2025-12-18 - Updated: 2025-12-18 - Topic: AI diagnostic - Tags: AI, adoption, security, processes, tools - For: General management, IT managers and heads of department - The enter 2.0 team ### Short answer An AI adoption diagnostic should review processes, data, documents, permissions, risks, in-house skills, vendors and success metrics before any tools are bought. The aim is not to decide whether the organisation will use AI, but where it can use it usefully, under control and in proportion. Some opportunities will be technical, others will be organisational and others will have to wait. ### Key points - An AI adoption diagnostic should review processes, data, documents, permissions, risks, in-house skills, vendors and success metrics before any tools are bought. - The aim is not to decide whether the organisation will use AI, but where it can use it usefully, under control and in proportion. - If knowledge is scattered across folders, old spreadsheets, applications with no export and private messages, the first challenge is the information architecture, not the model. - Use cases should be classified by risk level, human review, traceability, data protection and vendor dependency, and security is designed before the pilot, not after. - A good diagnostic ends in a short roadmap, and the right tool becomes clearer once the organisation knows what problem it wants to solve. ### An inventory of real work AI adoption starts by observing real work: emails, documents, calls, forms, reports, meetings, duplicated data, repetitive tasks and decisions that are delayed for lack of information. That inventory makes it possible to tell low-risk tasks, such as summarising public documentation, apart from sensitive ones, such as handling personal data, case files, employment information or financial records. ### Data quality and access AI needs context. If knowledge is scattered across folders, old spreadsheets, applications with no export function and private messages, the first challenge is not the model but the information architecture. The diagnostic should identify official sources, permissions, sensitive data, update frequency, the people responsible for validation and output formats. Without that foundation, whichever tool is chosen will have little room to deliver reliable value. ### Risk and governance Not every use of AI needs the same level of control. An internal text draft does not carry the same risk as a recommendation concerning a person, financial assistance or employment data. That is why the diagnostic should classify use cases by risk level, need for human review, traceability, data protection and vendor dependency. Security is designed before the pilot starts, not afterwards. ### The expected outcome A good diagnostic ends with a short roadmap: prioritised opportunities, risks, the data required, process changes, recommended prototypes, training and the purchasing decisions that genuinely make sense. Buying less and understanding more tends to speed up real adoption. The right tool comes into clearer view once the organisation knows what problem it wants to solve. ### Frequently asked questions #### What should we review before buying AI tools for our organisation? Review processes, data, documents, permissions, risks, in-house skills, vendors and success metrics. The aim is not to decide whether the organisation will use AI, but where it can use it usefully, under control and in proportion. Some opportunities will be technical, others will be organisational and others will have to wait. #### How do I tell low-risk uses of AI from those that need more control? Look at real work and at the kind of information each task involves. Summarising public documentation is low risk; handling personal data, case files, employment information or financial records is sensitive. An internal text draft does not carry the same risk as a recommendation concerning a person, financial assistance or employment data, so each use case should be classified by risk level and need for human review. #### Why might a good AI tool fail to deliver reliable value in our organisation? Because AI needs context, and if knowledge is scattered across folders, old spreadsheets, applications with no export and private messages, the first challenge is the information architecture rather than the model. The diagnostic should identify official sources, permissions, sensitive data, update frequency, the people responsible for validation and output formats. Without that foundation, whichever tool is chosen will have little room to deliver reliable value. #### What should an AI adoption diagnostic deliver? A short roadmap: prioritised opportunities, risks, the data required, process changes, recommended prototypes, training and the purchasing decisions that genuinely make sense. Buying less and understanding more tends to speed up real adoption. The right tool comes into clearer view once the organisation knows what problem it wants to solve. ### Connected services and cases - [AI and data diagnostic](https://www.enter20.com/en/services/ai-data-diagnostic/) - [IT governance, continuity and operations](https://www.enter20.com/en/services/it-governance-continuity/) - [Modular operations platform for a foundation](https://www.enter20.com/en/work/foundation-operations-platform/) - [Document automation with Python and human review](https://www.enter20.com/en/work/python-document-automation/) --- ## How to use AI safely in organisations that handle sensitive documents > Practical criteria for using AI with PDFs, case files, invoices, payslips and internal documents without losing control. - URL: https://www.enter20.com/en/blog/using-ai-safely-with-sensitive-documents/ - Español: https://www.enter20.com/blog/como-usar-ia-seguridad-organizaciones-documentos-sensibles/ - Updated: 19 September 2025 - enter 2.0 — Practical AI, governed data, dashboards, automation and information systems for organisations that need to make better decisions. - Published: 2025-09-19 - Updated: 2025-09-19 - Topic: Safe AI and documents - Tags: AI, documents, security, privacy, governance - For: Management, administration, IT and data protection leads - The enter 2.0 team ### Short answer Using AI with sensitive documents requires classifying documents, minimising the data sent, reviewing contracts, recording decisions, keeping human review in place and choosing local or controlled processing when the risk is high. The question is not only whether an AI tool is powerful. The question is what data it receives, where that data is processed, who has access, how long it is kept, how it is audited and which human decision depends on the output. ### Key points - What matters is not how powerful an AI tool is, but what data it receives, where it is processed, who accesses it, how long it is kept and how it is audited. - Classifying documents before processing them determines which can go to external tools, which need anonymisation and which should be handled locally or without generative AI. - It is wise to send AI only what is necessary and to record what was processed, for what purpose, with which tool, what it produced and who reviewed it. - With sensitive documents, AI output must pass human validation or verifiable rules before it feeds the systems the organisation runs on. - The architecture should match the risk: from a well-configured commercial tool to local processing, traditional OCR, deterministic rules or models in a controlled environment. ### Classify before processing Not all documents carry the same level of sensitivity. A public leaflet, an invoice, a payslip, a social services case file and an internal report should not go into the same AI workflow. An initial classification makes it possible to define which documents can be used in external tools, which require anonymisation and which must be processed with local alternatives or without generative AI. ### Minimise and record When AI is used, it is wise to send only what is necessary. Many tasks do not need the full document: specific fields, anonymised extracts or pre-filtered text may be enough. It is also wise to record what was processed, for what purpose, which tool was used, what output it produced and who reviewed it. That traceability makes it possible to correct errors and explain decisions. ### Mandatory human review AI can extract amounts, dates, names, categories or summaries, but with sensitive documents the output must pass human validation or verifiable rules before it feeds an operational system. Review need not be burdensome. It can be designed as an exceptions queue, a dry-run mode, a confidence flag or a comparison against business rules. ### Choose the architecture according to risk In some cases a well-configured commercial tool will be enough. In others it will make more sense to process locally, or to use traditional OCR, deterministic rules or models running in a controlled environment. Practical security means matching the architecture to the data, the team and the decision. Not everything needs the most complex solution, but sensitive material must not be treated as if it were public text. ### Frequently asked questions #### Can I use an external AI tool to process payslips or sensitive case files? It depends on how sensitive the document is and on the risk involved. A payslip or a social services case file should not go into the same AI workflow as a public leaflet. Classify documents first to decide which can be used in external tools, which require anonymisation and which should be processed with local alternatives or without generative AI. #### What information should I send to an AI tool if I only need to extract data from a document? Only what the task needs. Many tasks do not require the full document: specific fields, anonymised extracts or pre-filtered text may be enough. It is also wise to record what was processed, for what purpose, with which tool, what output it produced and who reviewed it, so that errors can be corrected and decisions explained. #### Do sensitive documents always have to be processed locally? Not necessarily. In some cases a well-configured commercial tool will be enough; in others it makes more sense to process locally, use traditional OCR, deterministic rules or models in a controlled environment. The architecture should match the data, the team and the decision: not everything needs the most complex solution, but sensitive material must not be treated as if it were public text. #### How can human review of AI-extracted data be organised without slowing work down? Review need not be burdensome: it can be designed as an exceptions queue, a dry-run mode, a confidence flag or a comparison against business rules. What is not optional with sensitive documents is that AI output passes human validation or verifiable rules before it feeds the systems the organisation runs on. ### Connected services and cases - [Document and data automation](https://www.enter20.com/en/services/document-data-automation/) - [IT governance, continuity and operations](https://www.enter20.com/en/services/it-governance-continuity/) - [AI and data diagnostic](https://www.enter20.com/en/services/ai-data-diagnostic/) - [Document automation with Python and human review](https://www.enter20.com/en/work/python-document-automation/) --- ## Dashboards are not the starting point: they are the visible part of the data system > Why a dashboard must rest on sources, definitions, responsibilities and quality routines to be reliable. - URL: https://www.enter20.com/en/blog/dashboards-are-the-visible-part-of-the-data-system/ - Español: https://www.enter20.com/blog/dashboards-no-son-principio-parte-visible-sistema-datos/ - Updated: 20 June 2025 - enter 2.0 — Practical AI, governed data, dashboards, automation and information systems for organisations that need to make better decisions. - Published: 2025-06-20 - Updated: 2025-06-20 - Topic: Dashboards and the data system - Tags: dashboards, data, indicators, BI, reporting - For: Senior management, programme teams, administration and analysts - The enter 2.0 team ### Short answer A dashboard does not fix a data system. It displays it. If the sources, definitions and responsibilities are weak, the dashboard simply makes that fragility visible with better design. The important part usually sits before the screen: what is captured, who validates it, when it is updated, how it is corrected, what permissions exist and what decisions will be made with each indicator. ### Key points - A dashboard does not fix a data system, it displays it: if sources, definitions and responsibilities are weak, it simply makes that fragility visible. - Building charts too early can lock in poorly defined indicators or create confidence in data that is not yet ready. - The healthy order is to diagnose questions, sources, definitions and minimum quality, and only then decide which visualisation helps people read reality. - A reliable dashboard rests on a data model, update rules, access controls, documentation and a review routine. - Each block of a dashboard should support a specific decision or piece of monitoring; fewer, better-defined indicators tend to build more trust. ### The mistake of starting with the visualisation It is understandable to want to see charts early. They help communicate and create a sense of progress. But if they are built too soon, they can lock in poorly defined indicators or create confidence in data that is not yet ready. The healthy order is to diagnose the questions, sources, definitions and minimum quality first. Only then does it make sense to decide which visualisation helps people read reality. ### What holds a dashboard up A reliable dashboard rests on a data model, update rules, access controls, documentation and a review routine. Without them, every change requires manual investigation and every discrepancy opens a fresh argument. It also needs limits. Not all data should be shown to every profile, and not every internal indicator should become public communication. ### Designing for decisions Each block of the dashboard should support a specific decision or piece of monitoring: spotting delays, prioritising resources, justifying funding, reviewing geographical coverage, identifying incomplete data or preparing for a meeting. When a chart does not help with any action, it is probably surplus or belongs in an exploratory report. Fewer, better-defined indicators tend to build more trust than a screen packed with metrics. ### Continuous improvement The dashboard does not complete the system. It makes it observable. Using it brings to light errors, missing fields, new questions and routines that need to change. That is why it is best treated as a living tool: an initial version, review with users, data adjustments, documentation and progressive improvement. ### Frequently asked questions #### Where should I start if I want a dashboard for my organisation? With what sits before the screen: which questions need answering, which sources exist, how the indicators are defined and what minimum quality the data has. Only then does it make sense to decide which visualisation helps people read reality. Starting with the charts can lock in poorly defined indicators or lend confidence to data that is not yet ready. #### Why can a well-designed dashboard still show unreliable data? Because a dashboard does not fix the data system: it displays it. If the sources, definitions and responsibilities are weak, the screen simply makes that fragility visible with better design. Reliability depends on what is captured, who validates it, when it is updated, how it is corrected and what permissions exist. #### How do I decide which indicators to include in a dashboard? Include only those that support a specific decision or piece of monitoring, such as spotting delays, prioritising resources, justifying funding, identifying incomplete data or preparing for a meeting. If a chart does not help with any action, it is probably surplus or belongs in an exploratory report. Fewer, better-defined indicators tend to build more trust than a screen packed with metrics. #### Is a dashboard finished once it goes live? No. A dashboard does not complete the system, it makes it observable: using it brings to light errors, missing fields, new questions and routines that need to change. It is best treated as a living tool, with an initial version, review with users, data adjustments, documentation and progressive improvement. ### Connected services and cases - [Data, indicators and dashboards](https://www.enter20.com/en/services/data-indicators-dashboards/) - [Bespoke operational tools](https://www.enter20.com/en/services/bespoke-operational-tools/) - [Indicators and dashboards for social monitoring](https://www.enter20.com/en/work/social-impact-dashboards/) - [Modular operations platform for a foundation](https://www.enter20.com/en/work/foundation-operations-platform/) --- ## Legal notice > Legal notice for the enter 2.0 website. - URL: https://www.enter20.com/en/legal-notice/ - Español: https://www.enter20.com/aviso-legal/ - enter 2.0 — Practical AI, governed data, dashboards, automation and information systems for organisations that need to make better decisions. This page summarises the basic terms of use of the public enter 2.0 site. ### Owner and contact This site represents the professional activity of enter 2.0. The email address contacta@enter20.com may be used for any communication. ### Use of the site The content is provided for informational and commercial purposes. Without prior analysis, it does not constitute legal, tax or definitive technical advice for a specific situation. ### Intellectual property The site's own texts, structure and materials belong to enter 2.0 unless otherwise indicated. Commercial reuse is not permitted without authorisation. ### External links Links to external services or documentation are provided for reference. enter 2.0 does not control the content of third-party sites or changes to them. ### Demonstrations and assistant The Lab mini-apps use fictional data only. The answers of the site assistant are generated by an AI model from the published content; they may contain errors and do not constitute an offer or a commitment. --- ## Privacy > Privacy policy for the enter 2.0 website. - URL: https://www.enter20.com/en/privacy/ - Español: https://www.enter20.com/privacidad/ - enter 2.0 — Practical AI, governed data, dashboards, automation and information systems for organisations that need to make better decisions. The policy focuses on the contact form, the site assistant and the security and analytics tools that may be enabled in Cloudflare. ### Data processed The form may collect your name, email, organisation, type of organisation, main problem, message, acceptance of the privacy terms, originating path and minimal technical data for security. ### Purpose The data is used to respond to the request, assess the fit of the service and keep a basic record of the contacts received. ### Infrastructure The site runs on Cloudflare Workers. Form requests are stored in Cloudflare D1. Turnstile may be used to reduce spam and abuse. ### Site assistant Questions sent to the assistant are processed by an AI model on Cloudflare's infrastructure to generate the answer. The site does not store them; it only keeps a daily usage counter without any content. Do not include personal data or confidential information in your questions. ### Lab and preferences The mini-apps run in the browser with fictional data and send nothing to the server. Theme and reading preferences are stored only in your browser. ### Retention and rights The data will be kept for as long as necessary to manage the conversation or professional relationship. You may request access, rectification or erasure by writing to contacta@enter20.com. ### Sensitive data Credentials, medical data, full bank details, personal documents and detailed confidential information must not be sent through the form. If the case requires sharing sensitive documentation, a suitable channel will be agreed.