AI for Cooperatives: Member Support With Governance and Limits

AI for Cooperatives: Member Support With Governance and Limits

To use AI for cooperatives' member support, start with a small, informational scope: questions about rules, deadlines, documents and the status of requests. Base every answer on the cooperative's own official documents, state clearly that the member is talking to an AI, and hand off to a person on any topic that involves a decision, sensitive data or a member's rights. Governance comes before technology: the bylaws, internal regulations, data protection law (LGPD) and the rules of your sector define what the agent may say and do.

Key takeaways

• A member is both a customer and an owner of the cooperative. A wrong AI answer can therefore be read as the institution's official position.
• The agent should answer only from approved documents (bylaws, internal regulations, assembly notices) and say so when it does not know.
• Personal and sensitive data need explicit limits: the agent collects the minimum, does not repeat what it does not need to, and never decides alone.
• Transparency is part of the product: disclose that it is an AI, offer a human channel and keep a record of every agent decision.
• The safest path is to map, limit, pilot one real flow, and only then decide whether to expand, adjust or stop.

What changes in member support when the customer is also an owner?

In an ordinary company, the customer asks and the company answers within a commercial policy. In a cooperative, the member has rights set out in the bylaws, takes part in assemblies, votes, can question decisions and expects equal treatment. That changes the risk of automated support.

If the AI says a benefit exists when an assembly has revoked it, the problem is not only a support error. It may be a promise made in the cooperative's name. If the AI treats two members in the same situation differently, it creates a fairness issue that the board will have to explain.

For that reason, the agent's design starts with three governance questions, before any choice of model or tool:

• Which answers is the cooperative willing to give in writing, automatically?
• Which topics depend on a decision by a person, a committee or the assembly?
• Which member data can the agent see, and for what purpose?

The answers depend on the sector (credit, health, agriculture, transport, consumer, labor) and on your bylaws. Where there is legal doubt, the decision belongs to the cooperative's legal counsel, not to the technology vendor.

Which requests can AI handle and which should it hand off?

A simple rule helps separate information from decision. AI answers well when the answer is already written in an approved document. It should hand off when the answer requires judgment, an exception, or access to delicate personal information.

A decision guide to start with:

• Can handle: opening hours and channels, documents required for a procedure, deadlines set in the internal regulations, how the assembly works, where to find minutes and notices, the status of a request already logged in a system.
• Can handle with human confirmation: scheduling an in-person appointment, simple record updates, resending a copy of a document that was already issued.
• Must always hand off: formal complaints, challenges to decisions of the board or council, exception requests, a member's withdrawal or expulsion, health matters, detailed financial situations, disputes between members, and any mention of threats, fraud or vulnerability.
• Must not do: interpret the bylaws in a specific case, promise outcomes, comment on votes, negotiate terms or communicate disciplinary decisions.

The policy of who approves what can be formalized. The article on an AI agent approval policy offers a template for defining actions the agent takes alone, actions that need approval and prohibited actions.

How do you make the AI respect the bylaws and assembly decisions?

The most common mistake is to connect a language model to WhatsApp and expect it to "know" the rules. A model does not know your cooperative's bylaws. If asked, it may invent a plausible answer. The way forward is to have the agent consult a base of approved documents and answer from it, a technique known as retrieval-augmented generation (RAG). AWS publishes a good introductory explanation of RAG if you want to read more.

For this to work with proper governance, the document base needs its own safeguards:

• One owner per document: someone in the secretariat, legal or the board is responsible for the current version.
• Version control: when an assembly changes a rule, the old document leaves the base on the same day the new one goes in.
• Separation of rule and practice: the bylaws are rules; an internal custom should not be presented as a member's right.
• Source citation: the answer says which document it came from (for example, the article of the regulations), so the member and the staff member can verify it.
• A refusal answer: if no document supports the answer, the agent says it will pass the question to a person instead of improvising.

There is also a security risk that is often forgotten. A member, or someone posing as one, may try to push the agent to ignore its instructions, reveal third-party data or promise something outside its scope. The OWASP Top 10 for LLM applications describes this and other risks. In practice, the defense is not firmer wording in the prompt. It is limiting what the agent can access and do: if it has no permission to see another member's record, there is nothing to leak.

What care is needed with personal and sensitive data?

Members share a great deal of information with the cooperative: documents, income, production history, health data in cooperatives of that sector, family data. The LGPD treats sensitive personal data with extra care, and the national data protection authority (ANPD) is the official reference for guidance and rules. Depending on the sector, there may also be sector-specific confidentiality rules. Confirm with legal counsel and with the cooperative's data protection officer (DPO).

From a design standpoint, a few principles reduce risk without relying on sophisticated interpretation:

• Collect the minimum: the agent asks only for what the flow needs, and does not request documents over WhatsApp when a more suitable channel exists.
• Verify identity before showing any individual data, using a method defined by the cooperative, not just the phone number.
• Do not repeat sensitive data in the conversation unless necessary. A reply such as "your request is under review" is usually enough.
• Define retention: how long conversations and logs are kept, and who can access them.
• Prevent member data from being used for other purposes, such as campaigns, without a proper legal basis and notice.
• Review the model vendor's contracts and settings: where data is processed, whether it is retained and whether it is used for training.

The article on LGPD compliance for AI on WhatsApp goes deeper on purpose, legal basis and records in conversations. Remember that consent is not the only possible legal basis, and the right choice should be validated by whoever is legally responsible for the cooperative.

To structure risk more broadly, the NIST AI Risk Management Framework is a useful reference. It organizes the work into mapping, measuring and managing risks, which fits well with the routine of a board and a fiscal council.

How do you ensure transparency with the member?

In a cooperative, transparency is not only a compliance item. It is part of the trust between member and institution. In an AI agent, it translates into concrete practices:

• Disclosure: the first message says the service is provided by an AI assistant and explains what it can and cannot do.
• A visible human channel: the member knows how to reach a person without having to repeat the conversation.
• Honest language: the agent does not pretend to be a human attendant or use a name that suggests it.
• Decision records: each answer stores the question, the source consulted, the action taken and whether a handoff happened.
• Accountability: the board periodically receives a summary of the topics handled, refusals and handoffs, and can present it to the council.

Handoff deserves special attention. A member who asks to speak to someone must be served, and the person who takes over should receive the context of the conversation. The WhatsApp AI agent human handoff playbook details triggers, transfer messages and what to record.

For observability, the agent's records need to be searchable. The OpenTelemetry observability primer explains the logic of logs, metrics and traces, which applies to agents just as it does to any system in production.

What does this look like in practice? An illustrative scenario

Illustrative scenario: a midsize credit cooperative receives many member messages before each ordinary assembly. The questions repeat: when the assembly is, how to take part, who can vote, where to see the agenda and how to access the year's financial statements.

The agent is configured to answer only that set of questions, based on the convocation notice, the bylaws and the internal regulations, all approved by the secretariat. It says it is an AI, cites the document each answer came from and does not access members' account data.

If a member asks whether they can vote, the agent explains the general rule in the bylaws and, for the individual situation, passes the conversation to someone in the secretariat with a summary. If a member complains about a council decision, the agent logs the topic, gives the formal channel and transfers. If someone tries to get it to give an opinion on a proposal being voted on, it declines and points to the official material.

At the end of the period, the secretariat reviews the conversations where the agent refused or handed off. Those reviews reveal gaps in the documents (frequent questions with no official answer) and help decide what to publish. This review cycle is where governance happens in practice.

What is a safe plan to start?

The method I apply in AI projects follows four moves: map, limit, pilot and transfer. In a cooperative, it looks like this:

• Map: list the current support channels, the most frequent topics, who answers each one, which documents support the answers and what data circulates. Set the baseline before automating.
• Limit: choose a few informational topics, list the data the agent may see (preferably none at first), and define permitted actions, handoff triggers and prohibited phrases. Get this scope approved by the board, legal counsel and the data protection officer.
• Pilot: put a single real flow live with a small group of members, full logs and a success metric agreed beforehand (for example, resolution without rework and answer quality checked by sampling).
• Transfer: hand the cooperative's team the documentation, the process for updating the document base and the review routine, and decide together whether the pilot expands, adjusts or stops.

To document the pilot, the AI pilot charter template helps record scope, risks, owners and stop criteria. To define how to judge the result, the guide on how to measure an AI automation pilot presents metrics and decision gates.

When the pilot moves to WhatsApp, decide early whether the channel will be the official API or the app, because that affects control, records and scale. The comparison of WhatsApp Business API vs app for an AI agent can help with that choice. Stopping the pilot is also a legitimate outcome: if the document base is not ready or the risk is not acceptable, the learning already has value.

Frequently asked questions

Does AI for cooperatives need assembly approval? It depends on what the bylaws provide and on the nature of the change. In general, using an informational assistant is a management decision, but it is advisable for the board to record the decision and inform the council. If the agent changes the relationship with members in a relevant way or handles data in a new way, consult legal counsel on whether a formal resolution is needed.

Can the AI answer questions about the bylaws? Yes, as long as it answers from the current, approved text, cites the source and does not interpret individual cases. When the question depends on a member's specific situation, the agent should pass it to a responsible person. Interpreting the bylaws remains a human responsibility.

Can the AI agent access a member's record and financial situation? Technically yes, but it should not at the start. Beginning without access to individual data greatly reduces risk and still resolves a good share of general questions. If that access is needed later, it should come with identity verification, minimum permissions, a log of every lookup and validation by the data protection officer.

How do you know whether the pilot is working? Compare against the baseline collected beforehand: volume of questions resolved without rework, answer quality in a sample reviewed by people, the rate of appropriate handoffs and complaints about the service. Also watch the governance signals: answers without a source, attempts to get around the rules and topics that should have been handed off. If those signals show up often, adjust the scope before expanding.

Sources

• ANPD: Autoridade Nacional de Proteção de Dados
• NIST AI Risk Management Framework
• OWASP Top 10 for LLM Applications
• AWS: What is retrieval-augmented generation